Slashdot Mirror
Strong Token-Based Authentication w/ Open Source Software?
"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."
... a link full of answers.
Talk about standard "AskSlashdot"...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
These guys 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 for about ten grand.
--
What happens when you outlaw guns
Hello,
I really like the dallas ibuttons. They have a good amount of open source software available but nothing that is off the shelf ready to go. I thkn htat you will need to tweak most of it. I really want to use one to store my gpg key inside of it.....
Douglas Calvert
they have a few sub projects that are working on Authentication systems. one or 2 are token based I think....give it a look
I am the Alpha and the Omega-3
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)!
It's the next generation RADIUS application. It's still being worked on by the IETF's aaa-wg, but it's nearing completion.
http://www.diameter.org
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.
Fully licensed blockchain psychiatrist
I would LOVE to have a securID clone. The only cost would be the KeyFob. I bet a company could make a significant amount of money by selling keyfobs and giving away their software. Make it open source so it can be scrutinized, and integrated into other systems.
Need Free Juniper/NetScreen Support? JuniperForum
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.
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
"Life is life." --Laibach
A free implementation of the SNK routines can be found in the open source Firewall Tool Kit.
There are several hardware and software implementations of SNK-004 available. Aside from Cryptocard, Safeword and Axent both offer hardware tokens which have a SNK mode.
I do not deploy Linux. Ever.
This product is considerably less expensive than SecurID. I spent several weeks testing the product last fall, and found no major security issues with their algorithm nor with the server software, just some minor unix permissions issues with the software installation process itself.
I do not deploy Linux. Ever.
I would hate to break it to the moderators, but kerberos is exactly what this dude needs. Its token based, can be used with a radius server, and is supported by win2k.
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.
To review, there are three factors that can be used to authenticate (positivly identify) someone:
Now, just because you're using a token does not mean that you are using a second factor to authenticate. For example, I could put my password on a floppy disk, lable the disk 'TOKEN' and then explain that I have to have that floppy to log in.
OK, so that's exaggerating, but sometimes things very close to that happen. A question to ask yourself is, "what specifically do I need to authenticate myself?" Let's answer that for a couple:
S/Key: you need the skey challenge information sent by the host, and your "passphrase," all of which get fed into the skey algorithm to produce the hash response.
You still need to remember that passphrase, and there's no simple way to detect that someone else has it too. So, you're effectively back to password authentication.
Now, S/Key is better than plain password because you should never use the same twice, so It's not possible to sniff the wire and find something that can be used again to authenticate.
BOTTOM LINE If you want 2-factor auth, skey is not for you. Otherwise, it's better than passwords. Just watch out for man-in-the-middle and other known weaknesses.
SecureID: You've got to have that fob. What the fob needs is the time, which it keeps itself, the seed, and the algorithm. If you had all of those, you could roll your own. Oh, and you need that PIN too. So, this really is two factor authentication: Something you know and something you have.
The problem with token-based authentication has always been that you have to put something on the token, and then prove that it's there without giving it up again. If I just store my password on the token, and then send it across the wire when asked, I've done nothing except hide from the user the fact that we're still using a password.
There are a couple of other ways to do this, thankfully. First is challenge-response. I say: "I'm john doe." You say: "Well, if you're really john, you'll know the proper response to this challenge: "Foo!" I now do some math on 'Foo!' and respond with: "Bar!" At which point you say: "Hi, John. Nice to see you again!" This works great so long as no one sees us, because a bad guy could now associate 'John Doe' 'Foo!' and 'Bar!' If he could now trick you into issuing the 'Foo!' challenge to his impersonated John Doe, he would have the correct response.
Second is what SecureID does: make up a (strong) secret algorithm that "no one else knows." The great thing about time-based algorithms is that they're time-based: the time becomes the challenge, and since the time is always different, it's impossible to issue the same challenge twice. The bad thing about time-based algorithms is that they're time based: if the clocks fall out of sync, the show's over.
So what's the answer? "That depends...." ;)
How about a combination of the two, a time-based challenge issued from the server that is "windowed" at the client. Not as strong, but the time sync isn't as critical either. This makes it possible to design the token without a super-accurate internal clock. (I have no idea how much accurate clocks cost.) Challenge-response is strong, so long as it's done right, so this may be suficient.
Hardware cost is the big factor here. This is what makes the ibutton and other customizable hardware a good choice. Of course ibuttons need the little blue dot readers, unless you spring for the USB fob to hold them, in which case your workstation needs USB support. There are other USB tokens, too, so this may be a possibility. The trick is finding one that works well with an open source USB stack.
The terms of the nasty agreement Dallas Semi makes you agree to before buying the java ibutton make it unacceptable for just about every purpose. First, it claims that when you buy an ibutton, you won't actually own it and you're in fact not buying anything at all (notice the wording "all title .. not limited to copyrights"):
And the nasty contract also stipulates that you can't take it apart to verify that it's secure or verify its lifespan, operating tolerances, etc:
So let's say you ran a security firm. And you were using the ibutton to fulfill a very important security contract such as locking doors or managing secure logins for a gazillion dollar corporation. You'd want to disassemble the ibutton to make sure it is really tamper resistant. You'd want to check to make sure the operating parameters really were as advertised. You'd want to check the device for durability. If you didn't, the client might be able to claim you didn't do due dilligence you might be liable for damages. Since the license for the ibutton prohibits all of these things, you wouldn't be able to use it.
Excessive failed login lockouts are not always the best idea. At the local university, nasty freshmen who want to sabotage another student repeatedly attempt bogus logins to that persons account until it gets locked. Victims find this particularly annoying when an assignment is due the next day and the system administrator has already gone home.
(And if the failed login lockout is active on every account, the system administrator may well find themselves locked out by a malicious user. Whoops).
Is that like when Gandalf couldn't remember the phrase to open the cave door to the mines of Moria?
"And like that
Do a search on google for "Palm Pilot STRIP" (be sure to include the palm pilot part - who knows what other kind of stuff you'll get). STRIP uses AES to encrypt the keys, so theoretically if you stole the pilot with the program not loaded and read straight from the chip, you'd be little better off. Be better to try brute forcing the password direct rather than stealing the token (pilot) and brute forcing that...
SIG: HUP