Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I have a home network which I access remotely quite a bit. But I'm worried about security. While I do have strong passwords, I'm worried that someone will acquire my password and use it to gain access.
I heard about "one time passwords" and even got to use them at my university. We'd just press a button on a device (or run an application on a phone) and get a generated password that would work for the next minute or so.
How can I set something like that up?
Are there systems that are easy to use and set up?
Has anyone played around with an SDK of one of these systems?
Where can I get a starter kit from?
EDIT: I'm running a mixed Linux and Windows network, and I'm vaguely hoping to use this for authenticating on both operating systems. (No, there's no domain controller, but I can set one up using Samba, I suppose.)
S/Key is fine for a low-cost OTP implementation.
If you're really worried about it, though, then worry also about your sessions being hijacked after they're initiated. In which case you might consider an SSH tunnel to encrypt your traffic. SSH also lends itself better to tunneling other applications through it once you set up your access. Finally, it you don't have an easy way to carry around an SSH client with you (or don't trust other people's SSH clients), there are a few web-based SSH clients that you could offer from your own server -- so it's under your control but available from any browser.
On Linux it's called S/Key: here
Not a button gizmo but you seed it and print off a list of one-time passwords to carry around with you. To make it work with a mixed env you'd need to get it working on your Windows box then get the Linux box to auth from that or (easier) get it working on Linux then link it to Samba so Windows can auth off it.
Google is your friend.
One approach could be as follows:-
U'll need to make a program which will generate a password which will only be accepted by ur home system for a specific time-frame.
For ex. When you run the program the output will valid be for a specific time duration and
will be accepted by your home security system as the system will also generate the same output while matching the hash, the trick is to get the same hash at both the places.
I guess this will need more brainstorming!!!!
As an addendum to renegadeMind's post one way to do this would be to have a program on both ends that generates a sequence of random numbers. A property of Pseudo-random number generators (PRNGs) is that if you start them with the same seed, they will continue to generate the same sequence of random numbers. So depending on your experience (or availability of technology) you could set your network up to generate a new password every x minutes. Then you could carry around a piece of software that would run on a phone or other embedded hardware that calculates what step in the sequence the PRNG is up to and then list the current password for you.
Having said that the security of your system would be limited to the seed you choose and the time you choose that each key is valid for.
In addition to this there is probably a software solution that will do this for you. IMHO it's better to take the existing implementation then reinventing the wheel.
Edit: Wikipedia has a good article here. The part on specific OTP technologies will probably be the most relevant.
Good luck though!
wiki article on PRNG
The first thing you need to decide is what authentication protocol will be your standard. I recommend Radius, especially for two-factor authentication in the enterprise. Radius is supported by all the major VPN & networking providers as well as all the major 2FA providers.
Then, consider the services you want to protect. For linux, this usually means PAM. Luckily, adding 2FA to linux via pam is pretty painless: http://www.wikidsystems.com/support/wikid-support-center/how-to/pam-radius-how-to/. For windows services, you will want to route them through ISA or the VPN.
You can configure all your radius requests to go through AD using the MS radius plugin IAS/NPS. http://www.networkworld.com/news/2010/050710-two-factor-authentication-through-windows-server.html?source=nww_rss
Finally, when choosing your 2FA solution, just make sure they support radius.
As for SDKs, that is a per-vendor situation. Here's a link to ours: http://www.wikidsystems.com/downloads/network-clients
hth, nick
Related
I recently read about decompilation of iOS apps and I'm now really concerned about it. As stated in the following posts (#1 and #2) it is possible to decompile an iOS which is distributed to the App Store. This can be done with jailbreak and I think with copying the app from memory to hdd. With some tools it is possible to
read out strings (strings tools)
dump the header files
reverse engineer to assembly code
It seems NOT to be possible to reverse engineer to Cocoa code.
As security is a feature of the software I create, I want to prevent bad users from reconstructing my security functions (encryption with key or log in to websites). So I came up with the following questions:
Can someone reconstruct my saving and encryption or login methods with assembly? I mean can he understand what exactly is going on (what is saved to which path at which time, which key is used etc., with what credentials is a login to which website performed)? I have no assembly understanding it looks like the matrix for me...
How can I securly use NSStrings which cannot be read out with strings or read in assembly? I know one can do obfuscation of strings - but this is still not secure, isn't it?
This is a problem that people have been chasing for years, and any sufficiently-motivated person with skills will be able to find ways to find out whatever information you don't want them to find out, if that information is ever stored on a device.
Without jailbreaking, it's possible to disassemble apps by using the purchased or downloaded binary. This is static inspection and is facilitated with standard disassembly tools. Although you need to have a tool which is good enough to add symbols from the linker and understand method calls sufficiently to be able to tease out what's going on. If you want to get a feel for how this works, check out hopper, it's a really good disassembly/reverse-engineering tool.
Specifically to your secure log in question, you have a bigger problem if you have a motivated attacker: system-based man-in-the-middle attacks. In this case, the attacker can shim out the networking code used by your system and see anything which is sent via standard networking. Therefore, you can't depend on being able to send any form of unencrypted data into a "secure" pipe at the OS or library level and expect it not to be seen. At a minimum you'll need to encrypt before getting the data into the pipe (i.e. you can't depend on sending any plain text to standard SSL libraries). You can compile your own set of SSL libraries and link them directly in to your App, which means you don't get any system performance and security enhancements over time, but you can manually upgrade your SSL libraries as necessary. You could also create your own encryption, but that's fraught with potential issues, since motivated hackers might find it easier to attack your wire protocol at that point (publicly-tested protocols like SSL are usually more secure than what you can throw together yourself, unless you are a particularly gifted developer with years of security/encryption experience).
However, all of this assumes that your attacker is sufficiently motivated. If you remove the low-hanging fruit, you may be able to prevent a casual hacker from making a simple attempt at figuring out your system. Some things to avoid:
storing plain-text encryption keys for either side of the encryption
storing keys in specifically named resources (a file named serverkey.text or a key stored in a plist with a name which contains key are both classics)
avoid simple passwords wherever possible
But, most important is creating systems where the keys (if any) stored in the application themselves are useless without information the user has to enter themselves (directly, or indirectly through systems such as OAUTH). The server should not trust the client for any important operation without having had some interaction with a user who can be trusted.
Apple's Keychain provides a good place to store authentication tokens, such as the ones retrieved during an OAUTH sequence. The API is a bit hard to work with, but the system is solid.
In the end, the problem is that no matter what you do, you're just upping the ante on the amount of work that it takes to defeat your measures. The attacker gets to control all of the important parts of the equation, so they will eventually defeat anything on the device. You are going to need to decide how much effort to put into securing the client, vs securing the server and monitoring for abuse. Since the attacker holds all of the cards on the device, your better approach is going to be methods that can be implemented on the server to enhance your goals.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I've created an API based on the RESTful pattern and I was wondering what's the best way to monitor it? Can I somehow gather statistics on each request and how deep could I monitor the requests?
Also, could it be done by using open source software (maybe building my own monitoring service) or do I need to buy third party software?
If it could be achieved by using open source software where do I start?
Start with identifying the core needs that you think monitoring will solve. Try to answer the two questions "What do I want to know?" and "How do I want to act on that information?".
Examples of "What do I want to know?"
Performance over time
Largest API users
Most commonly used API features
Error occurrence in the API
Examples of "How do I want to act on that information?"
Review a dashboard of known measurements
Be alerted when something changes beyond expected bounds
Trace execution that led to that state
Review measurements for the entire lifetime of the system
If you can answer those questions, you can either find the right third party solution that captures the metrics that you're interested in, or inject monitoring probes into the right section of your API that will tell you what you need to do know. I noticed that you're primarily a Laravel user, so it's likely that many of the metrics you want to know can be captured by adding before ( Registering Before Filters On a Controller ) and after ( Registering an After Application Filter ) filters with your application, to measure time for response and successful completion of response. This is where the answers to the first set of questions are most important ( "What do I want to know?" ), as it will guide where and what you measure in your app.
Once you know where you can capture the data, selecting the right tool becomes a matter of choosing between (roughly) two classes of monitoring applications: highly specialized monitoring apps that are tightly bound to the operation of your application, and generalized monitoring software that is more akin to a time series database.
There are no popular (to my knowledge) examples of the highly specialized case that are open source. Many commercial solutions do exist however: NewRelic, Ruxit, DynaTrace, etc. etc. etc. Their function could easily be described to be similar to a remote profiler, with many other functions besides. (Also, don't forget that a more traditional profiler may be useful for collecting some of the information you need - while it definitely will not supplant monitoring your application, there's a lot of valuable information that can be gleaned from profiling even before you go to production.)
On the general side of things, there are many more open source options that I'm personally aware of. The longest lived is Graphite (a great intro to which may be read here: Measure Anything, Measure Everything), which is in pretty common use amongst many. Graphite is by far from the only option however, and you can find many other options like Kibana and InfluxDB should you wish to host yourself.
Many of these open source options also have hosted options available from several providers. Additionally, you'll find that there are many entirely commercial options available in this camp (I'm founder of one, in fact :) - Instrumental ).
Most of these commercial options exist because application owners have found it pretty onerous to run their own monitoring infrastructure on top of running their actual application; maintaining availability of yet another distributed system is not high on many ops personnel's wishlists. :)
(I'm clearly biased for answering this since I co-founded Runscope which I believe is the leader in API Monitoring, so you can take this all with a grain of salt or trust my years of experience working with 1000s of customers specifically on this problem :)
I don't know of any OSS tools specific to REST(ful) API monitoring. General purpose OSS metrics monitoring tools (like Graphite) can definitely help keep tabs on pieces of your API stack, but don't have any API-specific features.
Commercial metrics monitoring tools (like Datadog) or Application Performance Monitoring (APM) tools like (New Relic or AppDynamics) have a few more features specific to API use cases, but none are centered on it. These are a useful part of what we call a "layered monitoring approach": start with high-level API monitoring, and use these other tools (exception trackers, APM, raw logs) to dive into issues when they arise.
So, what API-specific features should you be looking for in an API monitoring tool? We categorize them based on the three factors that you're generally monitoring for: uptime/availability, performance/speed and correctness/data validation.
Uptime Monitoring
At a base level you'll want to know if you're APIs are even available to the clients that need to reach them. For "public" (meaning, available on the public internet, not necessarily publicized...a mobile backend API is public but not necessarily publicized) APIs you'll want to simulate the clients that are calling them as much as possible. If you have a mobile app, it's likely the API needs to be available around the world. So at a bare minimum, your API monitoring tool should allow you to run tests from multiple locations. If your API can't be reached from a location, you'll want notifications via email, Slack, etc.
If your API is on a private network (corporate firewall, staging environment, local machine, etc.) you'll want to be able to "see" it as well. There are a variety of approaches for this (agents, VPNs, etc.) just make sure you use one your IT department signs off on.
Global distribution of testing agents is an expensive setup if you're self-hosting, building in-house or using an OSS tool. You need to make sure each remote location you set up (preferably outside your main cluster) is highly-available and fully-monitored as well. This can get expensive and time-consuming very quickly.
Performance Monitoring
Once you've verified your APIs are accessible, then you'll want to start measuring how fast they are performing to make sure they're not slowing down the apps that consume them. Raw response times is the bare minimum metric you should be tracking, but not always the most useful. Consider cases where multiple API calls are aggregated into a view for the user, or actions by the user generate dynamic or rarely called data that may not be present in a caching layer yet. These multi-step tasks or workflows are can be difficult to monitor with APM or metrics-based tools as they don't have the capabilities to understand the content of the API calls, only their existence.
Externally monitoring for speed is also important to get the most accurate representation of performance. If the monitoring agent sits inside your code or on the same server, it's unlikely it's taking into account all the factors that an actual client experiences when making a call. Things like DNS resolution, SSL negotiation, load balancing, caching, etc.
Correctness and Data Validation
What good is an API that's up and fast if it's returning the wrong data? This scenario is very common and is ultimately a far worse user experience. People understand "down"...they don't understand why an app is showing them the wrong data. A good API monitoring tool will allow you to do deep inspection of the message payloads going back and forth. JSON and XML parsing, complex assertions, schema validation, data extractions, dynamic variables, multi-step monitors and more are required to fully validate the data being sent back and forth is Correct.
It's also important to validate how clients authenticate with your API. Good API-specific monitoring tools will understand OAuth, mutual authentication with client certificates, token authentication, etc.
Hopefully this gives you a sense of why API monitoring is different from "traditional" metrics, APM and logging tools, and how they can all play together to get a complete picture of your application is performing.
I am using runscope.com for my company. If you want something free apicombo.com also can do.
Basically you can create a test for your API endpoint to validate the payload, response time, status code, etc. Then you can schedule the test to run. They also provide some basic statistics.
I've tried several applications and methods to do that, and the best (for my company and our related projects) is to log key=value pairs (atomic entries with all the information associated with this operation like IP source, operation result, elapsed time, etc... on specific log files for each node/server) and then monitorize with Splunk. With your REST and json data maybe your aproach will be different, but it's also well supported.
It's pretty easy to install and setup. You can monitor (almost) real time data (responses times, operation results), send notifications on events and do some DWH (and many other things, there are lots of plugins).
It's not open source but you can try it for free if you use less than 50MB logs per day (that's how it worked some time ago, since now I'm on enterprise license I'm not 100% sure).
Here is a little tutorial explaining how to achieve what you are looking for: http://blogs.splunk.com/2013/06/18/getting-data-from-your-rest-apis-into-splunk/
I have proprietary information (formulas etc) stored in a property list which is shipped with the app.
The property list will be created and edited by the property list editor in Xcode.
How can this property list be encrypted in iOS 5 to avoid reading the property list formulas by the user? I am looking for a solution that is very transparent and easy to implement.
First, this is a very specific form of the question "how do I prevent my application from being reverse engineered." The answer is you don't. You can implement some basic things to try to hide the information from an attacker. But there is no way to give your code to an attacker who has complete control of the hardware it runs on and still prevent it from being reverse engineered. For general discussion about this, see Obfuscating Cocoa. More versions of this question are listed in Secure https encryption for iPhone app to webpage.
So the real question is how to hide your information from the casual attacker, realizing that the dedicated attacker will defeat your scheme. When you ask the question that way, you realize that part of the answer is "as easily as possible because it would be silly to spend a lot of effort doing it if it's not going to be highly successful."
So shuffle the file with a long, random shared secret. Stick the shared secret in your code, and press on with life. If you want a good tool, I recommend CommonCrypto since it's built-in. Just remember that this is just obfuscation. As long as the key is in the software, you can't consider it "encryption."
If your secrets are valuable enough that you you have significant ongoing technical and legal resources to protect them, then mail me some more details and we can talk about how you create an anti-piracy and trade-secret protection team within your organization (I have experience doing that and would be happy to provide consultation expertise). But remember, Apple controls the iPhone top to bottom and has spent serious money to secure it. It's still jailbroken. Unless you are going to apply resources on a similar scale, you shouldn't expect a better result. In almost all cases, you are better off spending your resources making your product better than in protecting what you've shipped.
Examples are in the iOS Developer Library.
https://developer.apple.com/library/ios/#documentation/Security/Conceptual/CertKeyTrustProgGuide/iPhone_Tasks/iPhone_Tasks.html#//apple_ref/doc/uid/TP40001358-CH208
Ive been around the hacking block where I see people able to pull out email passwords and ftp details out of programs and I was wondering whats the best bet to protect those details while not crypting my vb.net program.
Encryption is the only way to really stop the dedicated hacker. But if this is about passwords that the program needs to know itself for operation, then it will have to have the key embedded as well (or maybe download it from your server every time). So the dedicated hacker could still get to it. Same problem the content industry faces in their Digital Restriction Management efforts : the player needs to be able to decode the media, they need to give people the player, so the player can be disassembled, and the encryption cracked.
All you can do is obfuscate things a little (or a lot).
Or give up on client software and run your program as a web service, where people cannot get to the code.
Obfuscation and encryption may delay a crack, but only for a while, because every encryption system can be broken with:
Access.
Enough time.
Because an exact digital copy of whatever can be made in minutes or seconds, time is guaranteed, so #1 becomes paramount.
Never store passwords in software or databases!. Take a look at the SO Q&A about Salting Passwords for the details.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Background
I recently joined a small start-up after working at a large company.
I'm not a professional system administrator, however, because of my programming and systems knowledge I am now the internal person managing our servers and infrastructure.
In the past, I never needed to document our system information: passwords (for servers, databases, routers, switches, etc), which servers were running which applications (both homemade and installed), server IP addresses, configuration file locations, etc...
The professional system admins always did this work, freeing me to focus on other areas.
Event that triggered urgency
I'd been a bit casual about moving this forward until I discovered that I didn't know where my main subversion configuration file was in /etc/apache2 (not to mention that the config file isn't under version control or backed up!) I realized that this needs to be addressed quickly.
Next step
I now have to figure out how to document all of this in a sane, elegant, access controlled manner.
I've heard of runbooks, but I don't know the best way or tools to manage them. My first thought was an excel/openoffice spreadsheet under version control.
Is there a good guide to maintaining runbooks? Good software? This must be a fairly common problem, how do you handle it?
I've actually had good success with a Wiki. Use something where you can control logins easily — Mediawiki is okay, but requires some PHP hacking — and build some templates for processes, inventories, and so forth.
Update
Actually, I must have needed coffee. Trac is pretty nearly ideal; better access control, integrated issue tracking, and a somewhat stronger text model. You can even tie it directly to your subversion repository so that you can hook actual scripts to their runbook pages.
Wikis are indeed a good approach. You can set up sharepoint for that and get nice features like update history, links that always point to current information and such.
If you use something like Puppet, (or Chef, or CFEngine, etc.) to build and manage your machines, then most of the runbook contents can live inside the puppet config, leaving you with a lot less stuff (just the location and password for the puppetmaster, if you take it to extremes!) to put in your wiki.