Strong Token-Based Authentication w/ Open Source Software? 87
"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."
i like the dallas ibutton (Score:2, Interesting)
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.....
blah (Score:0, Interesting)
What about Diameter? (Score:2, Interesting)
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
Re:iButton (Score:3, Interesting)
Re:What about Diameter? (Score:2, Interesting)
If he is not going proxy requests DIAMETER offers very little over RADIUS. There are tons of RADIUS servers - both free and commercial, both closed-source and open-source.
If he is going to use a open-source server thingy then it should be easy to adapt to a DIAMETER when/if he wants to.
I would hate to smash your small world (Score:2, Interesting)
Is it 2 Factor Authentication? (Score:2, Interesting)
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.
Re:SafeWord for Linux from Secure Computing (Score:2, Interesting)
ibutton purchase contract terms unacceptable (Score:3, Interesting)
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.