I have a web application, and am tasked with adding secure sign-on to bolster security, akin to what Google has added to Google accounts.
Use Case
Essentially, when a user logs in, we want to detect if the user has previously authorized this computer. If the computer has not been authorized, the user is sent a one-time password (via email, SMS, or phone call) that they must enter, where the user may choose to remember this computer. In the web application, we will track authorized devices, allowing users to see when/where they logged in from that device last, and deauthorize any devices if they so choose.
We require a solution that is very light touch (meaning, requiring no client-side software installation), and works with Safari, Chrome, Firefox, and IE 7+ (unfortunately). We will offer x509 security, which provides adequate security, but we still need a solution for customers that can’t or won’t use x509.
My intention is to store authorization information using cookies (or, potentially, using local storage, degrading to flash cookies, and then normal cookies).
At First Blush
Track two separate values (local data or cookies): a hash representing a secure sign-on token, as well as a device token. Both values are driven (and recorded) by the web application, and dictated to the client. The SSO token is dependent on the device as well as a sequence number. This effectively allows devices to be deauthorized (all SSO tokens become invalid) and mitigates replay (not effectively, though, which is why I’m asking this question) through the use of a sequence number, and uses a nonce.
Problem
With this solution, it’s possible for someone to just copy the SSO and device tokens and use in another request. While the sequence number will help me detect such an abuse and thus deauthorize the device, the detection and response can only happen after the valid device and malicious request both attempt access, which is ample time for damage to be done.
I feel like using HMAC would be better. Track the device, the sequence, create a nonce, timestamp, and hash with a private key, then send the hash plus those values as plain text. Server does the same (in addition to validating the device and sequence) and compares. That seems much easier, and much more reliable…. assuming we can securely negotiate, exchange, and store private keys.
Question
So then, how can I securely negotiate a private key for authorized device, and then securely store that key? Is it more possible, at least, if I settle for storing the private key using local storage or flash cookies and just say it’s “good enough”? Or, is there something I can do to my original draft to mitigate the vulnerability I describe?
I suspect you are asking for more security than the system, as described, can provide. Put simply, if you can’t control the client, it can (mis)use the SSO and device tokens in myriad (unintended) ways, as you are aware. It doesn’t matter how well you design the other parts of your system; this is the Achilles heel of your system.
Put another way, in the system as you have described it, you are tasking and trusting the client’s web browser to provide its device token and SSO token. Right? If so, how can you prevent the movement of these tokens to other devices? (See mitigation strategies, below.)
Now, to answer your questions head-on with this in mind:
It doesn’t hurt to do this, but it isn’t going to help, as I explain above.
I can’t tell you what “good enough” is. You should clearly communicate the “moving tokens” attack and help the customer make an informed decision.
There are certainly mitigation strategies that depend on your user install base and your tolerance for risk.
The key question, as I see it — think about the skills and abilities the kind of person who might move tokens from one machine to another — can your mitigation strategy make a significant dent in that behavior without degrading the system performance and usability for “honest” users?
Here are some ideas:
You could use two factor authentication, such as RSA SecurID. This won’t prevent the moving of machine tokens, but it would require that the TFA move with it.
You can try to obfuscate or hide the local copies of these tokens, but this seems like security through obscurity only.
You could check a machine’s MAC address. If it is harder to clone a MAC address than move a device token, this might be a useful layer of security.
You could try to require usage of certain customized browsers that “lock down” access to these tokens. This is just an idea; I don’t know if it is practical.
If you know that machines are not physically supposed to move, you could examine network properties to look for evidence that a machine is in a different network location, and thus, physical location.
If you query and store (on the server, not the client) computer configuration information, you could detect if a token moves from one machine with one configuration to a machine with a different one. (This approach, of course, would complain when a machine gets upgraded.)
Instead of storing local device tokens, you could require the installation of an application that provides an authentication API to the web application. This application could embed itself somewhere on the computer that is hard to hack, root out, or move. (In this way, this application would provide a “two-factor authentication” system for the machine.)
In concert with, or separately from the above idea, You could install a separate “phone home” application on the device. It would “check in” from time to time with your server. If it changes network location, device configuration, or stops responding you could deny access accordingly.
I hope this helps. I don’t consider myself a security expert, but I enjoy thinking through design problems. You might get some better responses if you ask over at https://security.stackexchange.com/)