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."
Here ya go... (Score:3, Troll)
Talk about standard "AskSlashdot"...
Well (Score:3, Informative)
Re:Well (Score:1)
- technik
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.....
Re:i like the dallas ibutton (Score:2)
However, Dallas (now part of Maxim-ic [maxim-ic.com]) has come out with a VERY cool SHA-1 based device [maxim-ic.com] This prevents someoen from intercepting the data sent form the iButton. It can be used as an end user device AND as a co-processor on the controller. This allows a very simple micro-controller to be used since the on board SHA-1 ibutton is used to validate the response to the challenge. When time allows I've really wanted to improve an existing design of mine for a touch & open door lock.
Note there are a number of vendors [maxim-ic.com] out there for iButtons - so you just might find something for Computers [maxim-ic.com]
Look at DotGNU (Score:2)
Re:Look at DotGNU (Score:3, Informative)
iButton (Score:5, Informative)
Re:iButton (Score:3, Interesting)
Re:iButton (Score:2)
Re:iButton (Score:2)
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.
Re:ibutton purchase contract terms unacceptable (Score:3, Insightful)
The Java iButton was developed by the same team on an improved version of their hardware. I would expect that it would have the same quality of implementation.
I haven't talked to the DalSemi folks much since the merger, but I regard them as one of the best vendors I had ever worked with.
Ben
Re:ibutton purchase contract terms unacceptable (Score:2)
Re:iButton (Score:3, Informative)
I would hate to smash your small world (Score:2, Interesting)
Re:I would hate to smash your small world (Score:3, Informative)
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: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.
CryptoCard leaves a little to be desired (Score:3, Informative)
Comment removed (Score:3, Insightful)
Re:SecurID clone (Score:1)
Or better yet, give away the keyfobs and sell the hardware and drivers. They could call it cueCrypt or cueFob or something.
Re:ACE/Agent for linux (Score:1)
CRYPTOcard is as close as it gets (Score:3, Informative)
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 (Score:2, Informative)
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
CryptoCard is basically SNK-004 (Score:2)
A free implementation of the SNK routines can be found in the open source Firewall Tool Kit [fwtk.org].
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.
Re:CryptoCard is basically SNK-004 (Score:1)
SafeWord for Linux from Secure Computing (Score:2)
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.
Re:SafeWord for Linux from Secure Computing (Score:2, Interesting)
DES, 3DES, and key length (Score:3, Informative)
wrong attempt lockouts let anyone lock any account (Score:3, Insightful)
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).
Re:wrong attempt lockouts let anyone lock any acco (Score:1)
This doesn't really cause a problem with CryptoCards unless the offending student/lUser has access to someone else's actual CryptoCard, since it is not a user's account that gets locked-out, it is the card itself. Anyone that leaves their CryptoCard out so someone else can lockout the card deserves what he/she gets IMO.
Re:wrong attempt lockouts let anyone lock any acco (Score:1)
And no admin should ever find himself lock out of his own system. If he did, it's because of something he did wrong.
S/Key (Score:1, Informative)
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:Is it 2 Factor Authentication? (Score:1)
Yup. This is how all hard tokens really work. The strength of a token is related to how hard it is to get that secret back out again. This is true whether you're talking about shared-secret tokens, or PKI tokens where the secret is a secret key.
The idea of "something you have" used to be more directly connected to the real world, such as a driver's license, a passport, etc. In the digital world, folks are trying to do the same thing remotely, and that begs the question of how you can verify the physical presence of a second factor if you can't see it? To date, it's all come down to math, and the keeping of secrets.
SecurID token is not as precise as you make out (Score:1, Informative)
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!).
RSA ACE/Server (Score:1)
Drawbacks to ACE/Server include:
- No Linux server
- Solaris admin tool (sdadmin) no longer fully controls the ACE/Server Solaris product. For full administration, you must use a Windows-based GUI. Ugh!
- Price
The odd thing we've seen is that many companies are getting rid of their token-based systems and moving to static password protected certificates in a PKI scenario. For some reason, they think the static password is more secure than a token!Do not use the Windows-based server. It is terribly unstable compared to the Solaris version, but what else is new.
PKI vs. Tokens (Score:1)
Re:RSA ACE/Server (Score:1)
The NT version is as stable as the solaris one, for all of the installations I've seen (I work for the largest reseller of ACE in Europe). I'd still go with solaris though, but the text based admin tool is appalling (but does everything). Web based admin is now an option in v5, but it's still limited...
Re:RSA ACE/Server (Score:1)
The only problem with sdadmin on Solaris is that whoever designed it assumed you would have a screen 50 rows long. Fortunately, the only thing missing from sdadmin are the time-based authentication settings.
The web-based admin tool was a major disappointment for us, as it is primarily just a help desk level "add/remove users" tool. It certainly isn't the "you'll be able to do everything you can do with the GUI" tool that RSA promised.
Re:RSA ACE/Server (Score:1)
Strong, Tolkien-Based Authentication (Score:3, Funny)
Secure Palm Pilot (Score:2)
Try Connexitor from Symas (Score:1)
They have an interesting product called Connexitor that implements single sign-on with various agents, such as RADIUS. They're also very open-source friendly.
Device as Token (Score:1)
CRYTPOcard DoS issue (Score:1)
CRYPTOcard is really a challenge-response (CR) token. There are several security advantages to CR. Unfortunately many protocols do not support CR at all, or only in certain instances. Out of the box implementations of ftp, ssh, rlogin are examples of non-CR based protocols. Sure, you can modify them to do CR but do you want to / can you do this?
Let us assume the answer is no for any number of reasons/excuses: ``I don't want to modify / I cannot modify (someone else owns/admins the box) / I don't know how to modify / I don't have the time to modify and maintain / ...'. What can you do?
No problem, you simply
operate in sequence mode.
In sequence mode, CRYPTOcard hides the CR. When the CRYPTOcard is initialized, a shared secret is established between their easyRADIUS server and your token. Let us call this secret N. When you 1st use the card acts as if a challenge of f(N+1) was given. There is no visible challenge - the card simply assumes what the challenge is and displays the response. Your CR unfriendly protocols and applications work nicely. The next time you login, the card and easyRADIUS server assume f(N+2) is used.
So what happens if your CRYPTOcard and your easyRADIUS server get our of sync? Say you start the login process, operate your token but get distracted with a phone call before you can login? After you call you try to login again. Now your token is at f(N+m+1) and the easyRADIUS (for your token) is at f(N+m). No problem, there is a ``grace window''. As long as the value you supply is within a few steps your token AND it is not prior to any previously used value you are allowed in. In our phone distraction example the easyRADIUS server would jump ahead to f(N+m+1). The next token operation would occur with f(N+m+2).
If your token and the easyRADIUS server get too far out of sync, you will need to have a token admin re-sync the token. Until the token is re-synced, you are out of luck.
So what was the flaw in 2000 that eliminated CRYPTOcard from consideration? Well whenever someone attempts to login to your account, the easyRADIUS increments the secret value!
Here is how the CRYPTOcard DoS works: Attempt to login to a card user's account a number of times. It doesn't matter what password you give, just fail a bunch of times. Before the DoS the poor users token and easyRADIUS server were at f(N+m). After the DoS the easyRADIUS server is at f(N+m+several) ... too far out of
the ``grace window'' to be used.
The user is locked out until the the
token and easyRADIUS are resynced!
This flaw was presented to CRYPTOcard. At first they didn't seem to understand. Next they didn't believe it. When it was demonstrated to them they responded that they ``never heard of anyone attempting to lock out an account in that way.''. I responded that system crackers and script-kids try dictionary attacks ...
sometimes attempting many 1000's of logins
just to see if the account has a easy password.
That folks looking for an open ftp server
sometimes bang away at an ftp password
for a while.
That web crackers will launch password
guessing attacks as well.
If ANY of those (plus others) were to
(unsuccessfully) attempt to login to your
account, YOU LOSE!
To be fair CRYPTOcard, after some effort said they were going to ``look into the problem''. They may have fixed it by now. Their work-a-round may be OK, or it may not-good-enough (you can't fix it be simply making the window wider) or it may be flawed/insecure (allowing replay attacks or CR guessing). There are a number of wrong ways to fix it, there are a number of ways that seem OK but contain a subtile flaw. Hopefully the CRYPTOcard folks did it the right way.
Before I were to deploy CRYPTOcard I would take a hard look at the DoS issues related to their tokens in non-challenge response environment ... or commit to
only doing CR logins for every device
in question (if that is possible).
Re:CRYTPOcard DoS issue (Score:1)
Perhaps you missed the point of the posting that you replied too ... in cases where CR
more is not possible, the DoS issue exists.
For example, there are people who cannot
use the commercial ssh (due to cost);
do not want to use the commercial ssh
(due to flaws in the product); or operating
in a non-SSH environment.
There are applications that were not designed
to use CR.
There are user interface situations where CR
is not available or desirable.
CR is better, but not always possible (for good or poor reasons). The point is in places were CR is not possible in any form, the DoS flaw was exists. Unless CRYPTOcard fixed it in the lest year or so, it still exists for a number of configurations and applications.
Even worse than the CRYPTOcard DoS flaw was how CRYPTOcard responded to the issue. We really DID want CRYPTOcard to win, but we were unable to get CRYPTOcard to respond effectively. It was too bad. In many ways CRPTOcard had the better product.
physical token testing (Score:1)
Your users will, hopefully by mistake, subject your tokens to abuse. To see how the tokens held up we created a torture test that simulated the real world token stress. We subjected several copies of each vendor's token to 3 cycles of the following test:
The SecureID tokens had 100% failures. Many of them failed the laundry test, sometimes on the 1st try. Most of the keychain FOBs cracked around the chain hole. We had 100% failure on these tokens.
Some CRYPTOcard non-FOB tokens (the credit card sized ones) failed the freezer test on the 1st try. Some non-FOB tokens momentarily lost their battery during the heat test and had to be re-initialized. About 2 in 5 passed.
Some CRYPTOcard FOB tokens failed the wash test after the 2nd week. Opening them up showed that water leaked ...
we presume that the seal cracked during the
1st week.
About 3 in 5 passed.
All of the Safeword non-FOB (credit card sized) tokens passed.
All of the Dallas-Semi iButtons passed.
Of 3 other vendors, all of whom are no longer in business, 1 passed 100% and 2 failed 100%.
Re:Authenex Alone in the Field for Price/Performan (Score:1)
I saw the releases but no price list - can you give us the price data?
Peter