Authorizing a computer to access a web application

Question

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?

Shurwood

Answer 1

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:

"So then, how can I securely negotiate a private key for authorized device, and then securely store that key?"

It doesn't hurt to do this, but it isn't going to help, as I explain above.

"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"?

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.

"Or, is there something I can do to my original draft to mitigate the vulnerability I describe?"

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/)

Bulbous

We will be using a one-time password for "unrecognized" machines, or those whose claims fail. As for the other suggestions, as I mentioned in the question I have to implement a "light touch" (meaning it requires no additional software), otherwise I would have gone that route. My original solution proposes a "best effort" in light of the fact that, as you said, I can't control the client given the constraints I am given, where if all else fails, we flag the account and require 1TP verification. – Shurwood

However, you mention detecting when the system has moved. I'd thought about using a geo IP API to record a users' approximate city. Expanding on that, perhaps I can employ heuristics over the client IP address to try and detect strange behavior, falling back to 1TP verification when something out of sorts is detected. For truly mobile customers, we could just require x509 auth or the installation of client software. Anyways, thanks for putting time into thinking about this. – Shurwood

Glad to help. I just found two other relevant SO questions that might give you some ideas: uniquely identifying a computer and device fingerprint for secure client access over a network. – Bulbous

@HackedByChinese Does this answer warrant the bounty? I admit that I found it because I was bounty hunting. :) – Bulbous

yeah I think you cover all the practical points of the situation. – Shurwood

Answer 2

What about capturing the MAC address of the computer and storing that information in the database as well? MAC Address's as you know are unique to all computers, verses an IP address.

Getting MAC address on a web page using a Java applet

Looking online there are several ways to capture MAC addresses via webpages and applets.

Misgiving

If I were to run a Java applet, I think I'd have it broker a private/public key securely from the OS, and then use HMAC from there. Using Java applets is an interesting idea, but it basically falls into the "requiring client software" category. Perhaps I'll revisit it, though. Thanks. – Shurwood