Strong Token-Based Authentication w/ Open Source Software?

durval asks: "I'm surveying token-based (2-factor) user authentication systems,and one of my prerequisites is that it must offer good support for open-source software (i.e, apart from any code that runs in the tokens themselves, all other software must either be standard open-source code --- like the RADIUS server -- or provided in source-code form, preferably under a GPL or BSD-like license). The other atribute is that it must integrate with RADIUS authentication."

"So far I've found significant data for the following ones:

OPIE, neé S/Key: ok, it's not a token-based system, but becomes very similar to one in functionality and security when you use a Palm handheld running PalmKEY or PilOTP (except that a Palm isn't tamper-proof hardware, but this is not a prerequisite for my application). The main problem I'm having with it is that I can't find an open-source RADIUS server that supports S/Key authentication, and the project seems mostly dead (no one is contributing anything anymore); on the positive side, it's a sound system with a published design that has withstood attack over the years, and it's completelly available under free terms [free both as in freedom and as in beer].

SecurID: this is the most famous and most used token-based authentication system available. It's been around for the bigger part of 10 years, and it's very easy to use: the user has a key fob or similar device, and types the number displayed on it -- this number changes once per minute, and is time-synched with the server -- appended to a normal fixed password - called PIN is SecurID's parlance. Its main problem is that it's very open-source unfriendly: nothing is provided in source-code form, under any license, and the required ACE/Server software doesn't even run on open-source operating systems (the closest it comes to this is running on Sun Solaris, for those who consider it open-source). Also on the negative side, it's based on a "secret" (although allegedly heavily audited) hash algorithm, and there has been more than one rumour over the last years regarding vulnerabilities in the algorithm.

CRYPTOcard: these guys use a challenge-response type of authentication mechanism, which I feel is inherently more secure than a time-based one like SecurID, if only because it's not displaying useable numbers all the time -- numbers which could be collected and used to exploit an hypothetical algorithm vulnerability, or else used -- in their 60-second window -- in conjunction with the PIN to impersonate the legitimate user). Also, the challenge/response algorithm is based on DES/3DES, which are good, public algorithms that have stood well the test of time (simple DES main problem is the key length, but 3DES solves that handly). Unfortunatelly, the company's open-source policy isn't very clear: they sell their own (closed-source) easyRADIUS server, and presently support no open-source alternatives (although they have promised support for freeRADIUS "real soon now").

So, has any of you experience -- good or bad -- with token-based (or similar) strong user authentication in open-source environments? I'm specially interested in hearing from people who managed to implement RADIUS authentication using S/Key; I'm also interested in hearing people's experiences with CryptoCARD or similar systems; for the reasons exposed above, I intend to keep my distance from SecurID and similarly expensive and "black-box" closed-source systems.

Thanks in advance to everybody; If you would rather comment privately, feel free to contact me by email (just substitute the AT and DOTs with the appropriate symbol and punctuations), and if you want to send it encrypted, my PGP key is on the servers, and can also be retrieved here."

Well

[mwalker]

These guys [v-one.com] are also very open-source unfriendly, but they do provide a solution not on your list. You can also buy a source code license to the Baltimore Toolkit [baltimore.com] for about ten grand.

iButton

[gwaihir]

Have you considered using DalSemi's iButton (www.ibutton.com)? It's basically a smart card encased in a stainless steel can. Java-based computer, RSA accelerator, etc. Decent documentation, free drivers, and a free IDE are available, supporting Windows and Linux. Programming for them is pretty simple, and they are about as secure as you can get--any attempt to compromise the button zero's the memory. And they are dirt cheap (relatively), the readers are about $15, and crypto buttons start at ~$35. They can also be used to control doors too (check out www.ibuttonlock.com)!

Re:Look at DotGNU

[the_2nd_coming]

damn...hear is the link [dotgnu.org]

CryptoCard leaves a little to be desired

[lactose99]

I currently maintain the token-based authentication system at my workplace (a large ISP). We use CryptoCards to authenticate users into our secure networks, coupled with their EasyRADIUS server for RADIUS auth. It works pretty well, and requires little maintence on our part (running on what seems like a stone-aged FreeBSD 3.3-STABLE machine) save the occational reboot if our routing equiptment on the inside of the CryptoCard connection freezes-up. My main beef with CryptoCards is their administration utility, cadmin. It offers basic user accounting (via username and group), but it lacks more intuitive cross-referencing capabilities. For instance, if a user were to find someone else's CryptoCard that was lost, and all the card shows is its serial number, there is no easy way to search the database for serial numbers to find the owner of the card! In circumstances like that, I usually have to blank the card, wait for someone to come crying that they lost it, and then reissue it (and scold their manager for letting an irresponsible person have the authorization for a CryptoCard in the first place). All in all, its a pretty OK system to use (I don't have any experience with the others, so I can't compare) save for the small admin headaches I get every once and a while.

CRYPTOcard is as close as it gets

[dmadole]

I have implemented a large-scale system based around the CRYPTOcard tokens, which I find nearly ideal. They use the FIPS 140 algorithm, which is well documented, last forever (replaceable batteries), are manually programmable without any hardware/software, and feature a neat event-syncronous mode that avoids the need for the user to key in the token, without significantly reducing security.

I did not use any CRYPTOcard software at all. We program the tokens manually from their keypad, which is easy enough. For the server end, we used the Radiator radius server, which is not free, but is reasonably priced, and great software (it's completely written in Perl!) It took about three days on-and-off to create a CRYPTOcard authentication module for it, completely in Perl (and I'm not a Perl guy). It's only about 25 lines altogether. The user data and keys are kept in a Postgresql database and it currently supports about 1,000 users.

The CRYPTOcard algorithm is simple (it's really just DES) and they even document their proprietary event-syncronous mode enough that I was able to completely support it. The manual programming options are also completely documented. I don't own the code I created, so I can't offer it, but it wouldn't be very difficult for someone to recreate it.

The tokens cost about $65 each, and they have a cool aluminum keychain fob token available, too (although we don't use those). These are as close to an open-source token as you'll get.

Feel free to contact me if you choose to go this route and need any help with the algorithms.

NetBSD Net/Radius port, OpenBSD BSD Auth, Hackery

[Paul Doom]

A few options for SKEY:

1) NetBSD's net/radius port has built in s/key support from MN.net.

2) OpenBSD 3.0 has BSD auth support for SKEY and tokens. I am not sure if the livingston-radius or cistron-radius ports use BSD auth or try to dig stuff out of the password files themselves.

which leads to:

3) You could use the Net::Radius Perl module and either the Authen::OPIE module, or a bit of C code to interface with the SKEY or OPIE libraries on the system.

I have not done any of these things. Have fun!

-Paul

DES, 3DES, and key length

[dmadole]

One more thing -- the original poster mentioned DES/3DES. The CRYPTOcards only use DES and only use a 64-bit key (maybe only 56 bits internally, I don't know). There is a mode where two keys can be entered but they are XOR'ed internally to a single key (this is so you can key a token without any one person knowing the key). This is completely adequate. There is not much point in using a longer key, because the challenge/responses are at most 64 bits. It's no harder to guess the key than the response itself. The best mode to use these in anyway is with numeric-only challenges and responses. It's most convenient, since you don't have to key hex digits. Although it doesn't seem so at first, it actually helps security in a way by discarding some bits from the response in converting from 8-digit hex to 8-digit decimal (it does ABC = 2, DEF = 3, like a phone keypad). This means that a hacker can brute-force a correct key from a past challenge/response pair, but it's only one out of a few million possibly correct keys that will generate that pair. Combine this with a five-wrong-attempts lockout, and it's pretty secure.

S/Key

[Anonymous Coward]

While I've not integrated it with Radius, I've have great luck with S/Key. Mostly, this was authenticating to variuos unix machines as well as Checkpoint FW-1. It is quite robust, provably secure (at least, the algorithm is if not the implimentation), and very portable. It's probably as good as you are going to get in open source.

Re:I would hate to smash your small world

[dmadole]

I hate to break it to the previous poster, but it may not be exactly what they need. Kerberos is good, but: 1. It doesn't work well with non IP-network situations, i.e. dumb-terminal applications, PPP dialup authentication, authentication over the phone (touch-tones) 2. As an extension to the above, it does not integrate well into legacy platforms and applications. Most things that can do user ID and password can do text challenge/response pretty easy. The CRYPTOcard can also be used as a OTP generator (in event-syncronous mode, with care), which eliminates the need for the challenge even. 3. Kerberos is token-based internally, in a way, but the authentication with the user is still passwords. You still need to deal with lost/compromised/*SHARED* password issues. The biggest advantage IMO of hard token systems is that the user cannot duplicate the key, even intentionally. Kerberos is really an encrypted-password based single-singon system, not exacly token-based authentication. It does not solve all problems, especially when behind RADIUS, which is one of the poster's requirements.

Re:iButton

[jmauro]

Except Maxim/Dallas is having a number of supply problems. They seem to be the redheaded stepchild of the Maxim buyout. Try to order just about anything from them and its a 10 week wait if you're lucky, and when the parts do show up they tend to be the wrong ones. Added to the fact that the software that runs them is not fully open or free they wouldn't meet the requirements of the poster in this case. It's really a shame. The buttons and the accompaning TINI's were very cool, but other more important things (like shipping them corrent and on time) have gotten in the way.

SecurID token is not as precise as you make out

[Anonymous Coward]

I work with a SecurID based system. The keyfobs (some refer to them as tokens) do not actually have to have an amazingly good clock - here's what really happens:

1) Slowly, the keyfob gets out of sync with the server.

2) Eventually the passcode you enter from the fob does not match with what the server expects (I believe it looks at the passcode just before and after what it expects as the window for "correct" passcodes).

3) The server then looks over a wider range of time (I think 1/2 hour) worth of passcodes to see if you entered one that was valid outside the narrow "correct" window.

4) If your passcode did occur in the larger window, it asks you to wait for the passcode to change on your fob and then enter the next passcode you see. It uses this to roughly synchronize the server with the fob you have (I assume by storing an offset in the securID database showing how far off the clock in your fob is).

5) You then have to log in again using the next passcode to show up on the fob.

So, it's actually a pretty robust system and doesn't require super accurate clocks on the passcode generating devices. It does however make it tricky to write an authentication system that handles the special case of token desynchronization because of the possible extra steps during login.

Posted anon as I'm not sure if that is confidental or what (though I didn't sign any papers my employer may have!).