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:
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
- 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.