As part of strengthening session authentication security for a site that I am building, I am trying to compile a list of the best ways to register a user's computer as a second tier of validation - that is in addition to the standard username/password login, of course. Typical ways of registering a user's computer are by setting a cookie and or IP address validation. As prevalent as mobile computing is, IP mapping is less and less a reliable identifier. Security settings and internet security & system optimization software can make it difficult to keep a cookie in place for very long.
Are there any other methods that can be used for establishing a more reliable computer registration that doesn't require the user to add exceptions to the various cookie deleting software?
If you're looking to do device authentication, you may want to consider mutually authenticated SSL. Here, you'd deploy a client identity certificate to each endpoint you'd want to authenticate. Then, you set the server up to require client authentication, so that a client would need to present a valid identity certificate in order to form the SSL tunnel.
This, of course, is not a perfect solution. In reality, this presents much of the same weaknesses as other solutions (to various degrees) Once your client identity certificates go to your clients, they are out of your control; should a client give their certificate to anyone else, you lost the device authentication that you have based on it. SSL identity certificates are generally stored in a keystore on the client which is encrypted with a password or other credential needed to unlock them. While a client certificate could still be compromised, it's somewhat stronger that just a cookie or something like that (assuming you don't have a client that is trying to give away its credential). In addition, you'd want to come up with some validation routine that a client would need to go though in order to get a credential in the first place (how do I know that this is a client device that I want to remember/register?).
Remember, these types of approaches only do device authentication, not users. There are more in-depth schemes already developed for device authentication than what I've mentioned; for example, 802.1x is a network protocol where an endpoint needs to present a client-side certificate to the network switch to get on a LAN. This is out-of-scope for a web application scenario, like what you've described, but the idea is the same (put a cryptographic credential on the client and validate it to establish the connection).
This, like all other security matters really, is a risk decision. What are you trying to accomplish with such a countermeasure? What are the threats you're trying to prevent and what are the consequences if someone does log in on an unregistered device? Only your situation can answer those questions and let you see the real risk, if you need/should mitigate it, and, if so, how strong of a solution do you need to get the risk level down to an acceptable level?
the best ways to register a user's computer as a second tier of
validation
From my point of view this approach does not offer much in the aspect of authentication.
You are not authenticating a user and have no idea who is using the PC that you would accept as being registered.
The way you describe it, this step should be a configuration rule in the firewall to accept connections from specific IPs only.
IMO the filtering of the PCs is the responsibility of a firewall and it would be much better handled by the firewall than any application level filtering.
Just think that you would have the overhead in your application to examine each request and decide whether to accept it or not.
Better leave this preprocessing overhead to the firewall. That's why it is there.
Related
While I understand the various options available for server to server authentication between REST services, I could use some clarification on the security implications of each approach.
I want a service to verify that a request received does originate from a legitimate calling remote service. No interactive users involved, assume the request happens as the calling service starts up. The three approaches usually mentioned are:
Use a fake user account and authenticate the client against the existing auth system
Use a shared secret / API key and sign the request
Use a client certificate (verifying the server is not a priority) 3.
The part I am missing is that it seems that all three methods depend entirely on the calling service's host (the client in the call) not being compromised. In the first approach this would give away the fake user password, but in the two other approaches an attacker could obtain the shared secret or the client certificate and impersonate the calling server just as easily as with approach number 1... so in what respect are 2 & 3 considered more secure?
If the host is compromised, the game is already over. You cannot hope to use network security techniques to provide guarantees about the end systems, that is not what they're meant for. Consider passwords, for example. When a user types in a password, the guarantee you have is that the entity that entered the password knows the password, that's all. Designing to be secure against compromised hosts is like trying to build a password scheme that only authorizes you if you're the real person - you're expecting a guarantee that the mechanism is not built to provide.
If you want to check the calling server is not compromised you might want to use TPM based verification of the calling server in case the machines have TPMs on them. Once it has been verified that it is not compromised any of the above 3 methods would be secure.(ref: http://en.wikipedia.org/wiki/Trusted_Platform_Module)
I am looking into ways of securing the channel between my client apps and the server.
I have a rich desktop client (win) and mobile client connecting to a webservice, exchanging data.
Using SSL certificates, server and clients may trust each other. On the secured connection i can exchange username and password and therefore authenticate the user.
However i have certain circumstances where a user must connect to the server via any of the two methods without his credentials but only a literal, like say, a license plate number.
I really want to make sure that in this case i ONLY allow client connects from devices i am sure i know, since there is no further checks on the authentication and a license plate number would be a pretty common literal.
How can i ensure that only "devices" which are known to my server, can interact with my server?
If you want to authenticate the device, you'll need to find a way for the device to prove what it is, without disclosing its secret.
A system similar to a number plate would be quite easy to spoof, for anyone in a position to see that number. Depending on how much control you have on this device, you might not be able to hide it, even if the connection to your server is secured with SSL/TLS.
A potential way to do this would be to use a cryptographic hardware token (or smart card). Some of these tokens can be configured to hold a certificate and private key, with the ability to use the private key without being able to export that private key. The cryptographic operations (signing and decryption) happen on the token itself.
You can use these to perform client-certificate authentication to your server. In this case, you would know that the client has that token. This could work on the condition that you know the CAs were issued its certificates only for key pairs in such tokens: there will be a cost in administering the CA to handle this.
This would at least allow you to tie the authentication to a particular token. Whether you can integrate this with your overall device depends on the kind of device you have.
Please check if TLS Pre-Shared Keys (RFC 4279) can be used for your scenario.
I've setup a Windows Azure database with the data accessible via oData. I'm trying to work out how to secure the connection between a WP7 device and the database. By secure I mean I only want users of the app to be able to access the data from within the app.
I've considered SSL but it's quite expensive for me - is there another way of securing this connection?
Thanks!
There are multiple definitions of "secure". You will need authentication, so Azure only lets the correct users access the data. This is usually handled by a user name and password supplied by the WP7 app.
The WP7 app needs to ensure it is talking to the correct server. SSL handles this using a digital certificate. There are other mechanisms but using something based on a public/private key pair is best because you can validate you are connecting to the correct server without being able to impersonate that server. However, the RSA algorithm used in most cases is computationally expensive.
The data sent between the WP7 app and Azure also needs to be confidential, including the user's password. This is normally handled by encryption. You an choose computationally less expensive algorithm or only encrypt certain data.
The data sent between the WP7 app and Azure also needs some form of tamper detection. Otherwise someone could corrupt the data sent or received. Maybe this is something you can accept for the app but it needs to be a way that an attack cannot easily reproduce. As Shanin's Maxim says, the attacker knows the system.
The problem is that SSL gives you all of these. Yes, it can be expensive but it is one of the best general purpose solutions available. You can change the cipher suites offered by Azure using using Group Policy, code or PowerShell.
If you do not want to use SSL, you need to know what you can sacrifice. In general I would not recommend doing your own encryption mechanism or protocol because us mere humans tend to screw it up.
I am a developer working on an internal web-based application, and I have been given responsibility to make sure the system is secure. I have no experience in this area, but I still want to do the best job I can: I'm in the middle of reading OWASP's guide (http://surfnet.dl.sourceforge.net/project/owasp/Guide/2.0.1/OWASPGuide2.0.1.pdf), but there is a lot of information to process, and unfortunately deadlines are deadlines.
Can the knowledgeable users here at Stack Overflow please poke holes in my design and show me where my understanding is lacking? If the entire idea is fundamentally flawed, knowing that would be appreciated, too. Thanks for any input.
This application is hosted internally, and should not be visible at all externally, even though it is accessed over our wireless networks. I trust our network engineers to handle this, though.
The users of this application are only a subset of all the employees in this corporate environment. In addition, even authorized users should be limited to only the information pertaining to them (which is largely an application-level concern, but I want to make sure exploits are not possible).
Security Framework for Internal Web Application (by a newbie)
All communication with the web server is done over HTTPS connections.
Logging in
User enters name and password, which are POSTed over an HTTPS connection
If the name and password are correct, generate a token, and store it in a cookie. Also store the cookie in the database for future lookup. The token should have an expiration date and is associated with only the user that generated it.
Requests
Check that the token supplied is still valid (not expired)
Check that the token is valid for the user making the request
If everything checks out, refresh the token's validity for another 30 minutes (or so)
Otherwise, deny access
That sounds good.
The token can either be a signed expiration date (signed with a private key stored on the server) or a sequence of cryptographically secure random bytes which is stored in a database.
Unless the token is specific to an IP address, everything must be done over SSL.
Independently of authentication, you'll also need to look out for SQL injection, CSRF, XSS, and other security holes.
Important consideration: The entire session has to be over SSL. Firesheep has demonstrated quite clearly that being able to sniff cookies (by being on the same network as the victim) leaves your users open to session hijacking.
Security is more than just logging in. You'll want to read up on SQL Injection and Cross-Site Scripting Attacks, on the very least (the two most common attacks against web-applications).
Look into CSRF attacks. They bypass cookie checks and company firewalls.
Is there any reason why I shouldn't use cookies/sessions for native mobile applications, usually used by browsers, to authenticate with my server and for subsequent API calls?
Clarification: It seems the de-facto method of authentication on mobile clients is token based systems like OAuth/XAuth. Why don't traditional browser methods suffice?
This depends on your application (your threat scenario to be more exact).
Some of the most common threats are
- eavesdropping (-> should encrypt)
- man in the middle (-> must authenticate other party)
- ...what are yours? (how secure is your cookie store,....)
A cookie at first only holds a token as proof that sometime you have successfully made an authentication. If the cookie is valid long enough or transport not encrypted, there is a good chance that someone someday will find out...
In addition you must take into account what additional security measures are in place, at first and most important SSL.
What is your authentication method (what credential does a client need to logon)? Do you have the possibility to work with authentication based on PPK infrastructure or is the communication "ad-hoc"?
EDIT
Wrt. to OpenAuth: as far as i understood the protocol its main concern is authentication delegation. A scenario where you authorize an agent to do some very specific task on behalf of another identity. This way you dont scatter your credentials all over the web. If you have OpenAuth in place, a client can use the protocol directly, too. So why bother adding another. But OpenAuth explicitly states that with a direct client scenario you again run into security issues as now the token is available on the device and must be protected accordingly (as you must do with your cookie).