Let's face it. Tokens are just cool to geeks.
While early on, working for a pi firm in 1999, I used Cryptocards, I was hooked.
Here was one of those little things that gave you a challenge, and you had to put into your cryptocard, get an answer back, and type out the response. A correct response couldn't be used more than once. On top of everything, the cryptocard itself had a PIN when you turned it on. It was, in a word, pretty foolproof. There's always the option of "put a gun to my head and ask for the pin", but I think the things even have a "duress pin", which bricks the device.
Cryptocards aren't user-friendly, tho. It gets annoying.
The most popular maker of this stuff on the market is a little company called RSA. They have a product that they call "SecuriD". These are still considered "two-factor" authentication (something you have, plus something you know), even though they aren't technically "challenge-response". These little dogtag-sized chips just print out a cyclic number every 60 seconds. They adapt themselves to applications by "supplanting" the password mechanism. If your password is "cookie", you would type "cookieNNNNNN" into whatever password dialog box you liked. Their server knows to chop the last six digits off, try that against its crypto algorithm, and try the rest of it against the password db.
The thing I hate in general about this kind of token is that if you get logged out, you're screwed and have to wait for the next token to come up. Even worse, if you're logging in over a slow session (think cases of extreme processor slog) it's entirely possible that by the time you're prompted for your password, or by the time the system gets around to calling the authenticator, it will have expired.
Any discussion about this stuff cannot ignore S/Key or OPIE, which stands for "Onetime Passwords in Everything". This IS totally open-source, and I use it, especially in places where I don't trust the computer or the network. But it's more complex than it needs to be. In my setup, opie can be used WITHOUT ever typing your real password, so it's not quite two-factor. It's not so much about making the auth stronger, as it is about making eavesdropping useless.
Ten years ago, this was james-bond kind-of stuff, or at the very least, large-enterprise and government-contractor grade. Now, with phishing and social engineering on the rise, and people just Not Getting Any Smarter, you can get one of these things to protect your paypal account, or even your World of Warcraft Account.
I should note that it's getting increasinly common to see this done as a cell-phone app. Either one that runs over sms, and generates a key on the fly, or an app that emulates a hardware token. In general, I'm not a fan of this because SMS is forgeable, and people never, ever, lock their cellphones. Besides, having my server require a magic tamagotchi for a login is still cooler in my brain than requiring Another Piece of Software.
I've wanted to do token-based auth of some kind with my systems for a while. The two problems with this are: A) the software is expensive and B) the tokens are expensive. About a year ago, I discovered a company called MyPW, that makes a simple third-party auth answer. There's no software to buy, and they basically "loan" you the tokens, in exchange for charging a very small fee for each auth request. The tokens (and ostensibly, the software) they use are made by a company I hadn't previously heard of, called Vasco. While the algorithm the tokens use is still not open, and it appears thus, impossible to write your own implementation, at least, at the entry cost of ten dollars, Anyone Can Do This.
I've ordered some tokens, and in my excitement, have started looking at implementation details. To quote taylor swift..."And then I wasn't excited anymore." In reading up on this, I've discovered the following:
Near as I can tell, not every SSH client implementation has the ability to display these kinds of challenges to users. However, there's an RFC for it, so that's cool. And apparently, that RFC does specify that multiple challenges can be presented, at least in ssh version two (which everyone should be using).
Looking over a few things, it seems as though I can do multiple prompts for a user, with ssh (I'll have to testbed this somewhere), but it's not clear to me how the mypw Pam Module prompts a user. However, some other systems, like Webmin, are only configured to do straight HTTP auth. And I rather like that a user cannot see any part of webmin without answering the http query. (I should also note that my webmin instances don't use system passwords, as a failsafe in case something mangles the password file).
I can't find a pam-wise way of doing things the "RSA Way" (i.e. with your password and your token-key mishmashed).
I also can't find a way that Pam Module A can modify the user's supplied password on the stack before passing it to Module B. This may totally be possible, if coded into the module itself, I just don't see a config-wise way of doing it, and don't understand the pam api well enough.
I think the way openssh makes its calls to pam, there could be an issue. What happens if I am prompted for my password, and get it right, then my tokenid, but get it wrong? I believe the pam stack starts over from the top, which means I have to re-type my password. Look at this the other way around. Let's say my tokenid is first, and I type it right, but I mangle my password. I have to then wait, since the system won't accept the same id twice. Allowing the pam module to maintain a cache, and permit on subsequent auths doesn't help either, since pam has (as far as I know) no concept of ip addresses or sessions. (In other words, I don't think pam can differentiate between subsequent auths on the same session, and a completely different auth session from a different machine).
Finally, in the "readme" that mypw supplies, they say to implement your pam setup as follows:
#%PAM-1.0 auth required pam_xmlrpc.so service=system-auth #auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth
I see at least a few things wrong here.
The service=system-auth thing only applies to pam_stack, so it's probably a typo. It's a minor typo, but this is the documentation for how to let people securely log into your server, so I kinda expect a little polishing.
To look at this, this basically appears to act ONLY on the token-based password, which is inherently LESS secure than anything else. After all, if you steal my car keys, there's my WHOLE password sitting in plain text, you just have to guess my username.
Other missing things include:
- A way to define from the pam.conf file where the config file lives.
- A list of what options the pam module supports.
- A manpage.
- A definition for how to determine what happens if the auth server can't be contacted.
- A neat way for users to manage their own tokens.
- A way to support user-tokens via home-directory file instead of one-big-system file.
- The one-big-system-file approach, since it's a text file, doesn't scale. It should probably get some kind of db-file support.
- A way to manage "drift", i.e. how far expired a token may be. (That is, for slow and laggy connections, I'd like to see the option to still make a password one-time-only, but allow its use up to five minutes past its prime).
I think I'm going to write to these guys and suggest that they try to push in a FreeBSD port, as well as bringing this blog post to them.
Thsi looks like a fairly basic project to work with C on, if I spoke it...but I'm not comfortable cutting my teeth on such a critical piece of software. I guess I'll see what they say.