A couple of weeks ago, Hunter and I were talking about passwords. More to the point, the inadequacy of passwords and why we haven’t moved beyond them yet. This touches on several points that I made last year. Specifically, that a password that is secure enough starts to restrict its usability.
In a nutshell, authentication is proving that you are who you claim to be. The standard ways of authenticating yourself are through: something you know (e.g., a password), something you have (e.g., a token) or something you are (e.g., biometrics, facial recognition, etc.). So the claim here is that the human brain is not good enough at remembering things to make “something you know†secure. Unfortunately, it’s cheap and easy to implement. Two things which are always important.
Our other options are something you are or something you have. Something you are can be complicated and expensive. At the very least, it requires a something-you-are-reader anywhere you want to authenticate yourself. Want to use your computer at home to access the one at work? Make sure you have your trusted, secure something-you-are reader set up (finger print scanner, iris reader, etc.). Want to authenticate from an Internet cafe? Good luck. Besides that, there’s some argument that many of the approaches used to date are not secure; and there’s the creepiness factor.
So, something you have. This one can also get potentially expensive, but is potentially cheaper than the rest which is why you see it being used by banks to access online accounts. Here we have some sort of hardware “token.†Most traditionally, these tokens have a simple processor, a clock and an LED display. The display shows a pseudo-random number. At a regular interval, the number changes. To log into a service, you key in the random number and maybe an a password. Since the service you access knows the pseudo-random number generating algorithm for your device and the time, it can validate the number you entered. Allow a little bit of logic to deal with clock skew and you are set. Several companies will sell you something like this. Of course, you pay for the devices, pay for the authentication server and then, in some cases, pay for each service.
So, what about an open source solution? This is in-part what Hunter and I were talking about. Imagine if you had an encrypted private certificate stored on a thumb drive. You could fairly easily write up a challenge-response protocol to validate the certificate. Since it’s certificate based, you could authenticate without a centralized authentication server – the ability of the certificate signed by your (private) certificate authority to participate in the response authenticates the certificate holder. You could create PAM modules for unix/linux and the equivalent for Windows and Mac. On the client side, stored on the same drive, you would have software to mediate the authentication.
I could see two ways for the client to do this. 1) a separate process that connects to the service’s server and essentially allows access for this IP. The service then needs to talk to the server-side piece to see if a user is allowed to access from the IP. That plus a password and you’re in pretty good shape. No connection to the authentication service means that you can’t log in. 2) Try to create a service along the lines of stunnel that mediates all communication between the client and the service. This is extremely ugly and I wouldn’t recommend it.
So, what are the advantages/disadvantages?
- Advantage: low hardware cost. Most every computer has a USB reader
- Advantage: relatively simple to implement
- Disadvantage: even the cheapest thumb drives are on the order of $5 each
- Advantage: many people already have one and they could be used for this purpose without wasting too much space
- Disadvantage: to a certain extent, this is not secure. Specifically, there’s no proof that the user actually has the key as opposed to a copy of the certificate and the algorithm required.
#5 seems like the biggest problem. As an open source product, all one needs is the certificate to spoof the token. Okay, we could incorporate the USB serial number, but that can also be copied. Ideally, all the processing would occur on the thumb drive, but that takes us out of the realm of commodity. So, the risk here is that using your token on a compromised computer compromises the token in the same way that using your password on a compromised computer compromises your password.
This is definitely not a hypothetical problem, but I don’t know how to resolve it. Is it still worth implementing something like this? If folks have thoughts or suggestions, I would love to hear them.
