Forgot your password?

Strong Token-Based Authentication w/ Open Source Software? 87

Posted by Cliff
from the proper-security-access-is-required dept.
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."

This discussion has been archived. No new comments can be posted.

Strong Token-Based Authentication w/ Open Source Software?

Comments Filter:
  • by FortKnox (169099) on Friday November 02, 2001 @12:19PM (#2512376) Homepage Journal
    ... a link [] full of answers.

    Talk about standard "AskSlashdot"...
  • Well (Score:3, Informative)

    by mwalker (66677) on Friday November 02, 2001 @12:22PM (#2512389) Homepage
    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.
    • They aren't totally OS-unfriendly but they also aren't inexpensive. FWIW, they do make use of Red Hat in their Smartguard [] appliance and their field guys are Linux saavy.

      - technik
  • by dfelznic (8812)
    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.....
    • The iButtons are really slick little devices. On problem with normal ones? The data can be intercepted off the 1-wire data bus if someone gets access to it... Not good.

      However, Dallas (now part of Maxim-ic []) has come out with a VERY cool SHA-1 based device [] 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 [] out there for iButtons - so you just might find something for Computers []

  • they have a few sub projects that are working on Authentication systems. one or 2 are token based I think....give it a look
  • iButton (Score:5, Informative)

    by gwaihir (101320) <gwaihir@mail.cSLACKWAREom minus distro> on Friday November 02, 2001 @12:26PM (#2512412)
    Have you considered using DalSemi's iButton ( 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!
    • Re:iButton (Score:3, Interesting)

      by gorilla (36491)
      If all you want is local authentication, then you can consider using a simple serial number button like DS1990A, which costs about $2. If you want remote authentication, I'd probably consider a DS1963L, which is about $10, but supports better remote authentication.
      • Problem is if someone taps into the 1-wire bus and knows how the system works, they can grab the data and emulate it using a simple Microchip microcontroller. For security, you should use the new SHA-1 iButton which uses a challenge setup to encrypt data. See above []
        • Yeah, that's why I said consider using the DS1990A. It's not suitable if there is any possibility of someone being able to tap into the bus. The SHA-1 button (DS1963S) is very closely related to the DS1963L, they're both designed for monetary applications, and therefore both secure.
    • 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"):

      2. COPYRIGHT. All title, including but not limited to copyrights, in and to the Java powered i Button product are owned by DS. All title and intellectual property rights in and to the content which may be accessed through use of the Java powered iButton product is the property of the respective content owner and may be protected by applicable copyright or other intellectual property laws and treaties. This license Agreement grants you no rights to use s...

      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:

      3. INTEGRITY OF Java powered iButton. You may permanently transfer all of your rights under this License, provided the recipient agrees to the terms of this License. You may not tamper, attempt to open, deliberately subject to environmental stress beyond its operating parameters, copy, reverse engineer, revise, or misuse the Java powered iButton.

      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.

      • As part of Sun's encrypting firewall project, I conducted a code review of the Crypto iButton with Dallas Semiconductor's development team. Got some tips from Whit Diffie before going there and had Tsutomu Shimomura on speaker phone during the review. We were quite satisfied with their physical and code implementation. A few code-paranoia suggestions were made and were subsequently implemented. But the opinion was that it was secure even without those changes.

        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.

        • That's all fine and dandy, but when you're working for a security firm, it's your job to trust as few things as possible, which means you check everything yourself. Anyone company who expects security experts to "trust them, it's secure" clearly has no understanding of the security field. Independent testing is important, and security experts will immediately assume that anyone who tries to forbid public scrutiny has something to hide.
    • Re:iButton (Score:3, Informative)

      by jmauro (32523)
      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.
  • What about Diameter? (Score:2, Interesting)

    by frascone (466844)

    It's the next generation RADIUS application. It's still being worked on by the IETF's aaa-wg, but it's nearing completion.
    • by isj (453011)
      DIAMETER has neared completion for the last two years :-) "real soon now". I have no knowledge of decent DIAMETER servers (performance, setup, flexibility)

      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.
  • by lactose99 (71132) on Friday November 02, 2001 @01:05PM (#2512636)
    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.
  • SecurID clone (Score:3, Insightful)

    by austad (22163) on Friday November 02, 2001 @01:06PM (#2512638) Homepage
    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.
      1. I bet a company could make a significant amount of money by selling keyfobs and giving away their software.

        1. Or better yet, give away the keyfobs and sell the hardware and drivers. They could call it cueCrypt or cueFob or something.
  • by dmadole (528015) on Friday November 02, 2001 @01:33PM (#2512775)
    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

    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!

  • CryptoCard's challenge-response mechanism is Digital Pathway's old 'SecureNetKey' algorithm, aka SNK-004.

    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.

    • They are the same if you stick to hex challenge/responses. Their decimal modes are different. SecureNetKey uses A=1, B=2, C=3, D=4, E=5, F=6 (or is it A=0, ..., I forget) CRYPTOcard uses ABC=2, DEF=3 Of course, this is an easy mod to make.
  • Secure Computing [] offers SafeWord [], a token based authentication server which runs on Linux RedHat v6.1 (and numerous closed-source OSes).

    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.

    • We have Safeword Plus deployed on multiple platforms (servers running under Solaris, with sshds authenticating against it, also RADIUS hooking into the NT domain for VPN authentication, as well as their NES plugin on Solaris for protecting web servers), and have nothing but good things to say about it. The cost per seat has already been mentioned (we got our fobs in bulk for around $10/ea, compared to the $100+ for SecurID fobs), but also the ease of integration cannot be dismissed. Hooking it into ssh was the hardest part, requiring a bit of recoding. For everything else, it just went.
  • by dmadole (528015) on Friday November 02, 2001 @01:52PM (#2512866)
    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.
    • Combine this with a five-wrong-attempts lockout, and it's pretty secure.

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

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

        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.

      • Most systems like this allow you to look the account for a certain period of time. This is usually sufficient for most applications since it takes away the "fun" of locking someone else's account and at the same time defeats most hacking attempts. Many brute force hacking programs can try hundreds of passwords a minute, but if the account is locked for even 10 minutes after every 3 attmepts it will take the wind out of the hackers sails.
        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)

    by 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.
  • To review, there are three factors that can be used to authenticate (positivly identify) someone:

    1. something you know (a password)
    2. something you have (a token)
    3. something you are (thumb print, retina scan)

    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.

    • by 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!).
  • Frankly, the RSA ACE/Server (SecurID tokens) is about the best there is. Additionally, the newest versions include a Linux client that can be integrated into a Linux system via PAM, which should mean you can token authenticate just about anything PAM handles.

    Drawbacks to ACE/Server include:

    • No Linux server
      Do not use the Windows-based server. It is terribly unstable compared to the Solaris version, but what else is new.
    • 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!
    • Companies are abandoning token based authentication in favour of PKI because of one thing $$$. Token based costs more because of lost tokens, dumb users requiring support staff, etc. PKI has a higher initial cost but is pretty much set and forget.
    • Linux port is in the offing, according to RSA..

      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...
      • Hmmm, I work for the largest ACE/Server reseller in the world and our experience with the NT product is that it is significantly more prone to failures than the Solaris product. Try pumping thousands of authentications through as fast as you can and see which one grinds down. Of course, shops willing to run Windows for mission critical servers aren't terribly worried about performance in any case, so I guess it's a wash.

        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.

        • Most of our users are sensible enough to realise that you can't expect to run a server that's going to work hard on an NT box :) The other problem with sdadmin is that you have to press tab at least 1000 times per screen, which is a total PITA :) We are telling people to hang fire on v5, as it seems a little flaky, but yes, I know what you mean. v5 in general was a bit of a letdown, the promised mesh architecture with multiple masters never appeared... Strangely enough, I have a feeling we support the UK arm of your employers ACE server, but I couldn't say for sure without checking... (I could be wrong though, but I know we do business with you for something or another)
  • by tswinzig (210999) on Friday November 02, 2001 @02:44PM (#2513165) Journal
    Is that like when Gandalf couldn't remember the phrase to open the cave door to the mines of Moria?
  • 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...
  • See

    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.

  • Phoenix Technologies (think BIOS) has a new product out called DeviceConnect which implements two factor authentication without a separate token. They turn the device into the token in such a way that it can't be duplicated. If a PC is trusted then it is allowed onto the net (with a sutiable user password). If not, then it isn't. The advantage is that you don't need a separate hardware token, and the associated management. It also removes the user from the equation -- don't need to mess with transfering a PIN from a Token. The disadvantage is that it isn't as mobile - you have to be at a trusted PC. If anybody is intersted in this I can send along details. Oh, and the auth. server for it is standard RADIUS.
  • Initially CRYPTOcard looked like a wonderful solution. I was forced to reject them because of a design flaw back in 2000.

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

  • One important aspect of token selection is how well they survive hard conditions. Sure you may have a token that works in your OpenSource environment, but will it continue to work in the physical environment?

    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:

    • Day 1: Send your token thru a typical laundry wash cycle and tumble dry cycle.
    • Day 2: Leave the token on the dash of your card for 1/2 day (if on a warm day) or subject the token to a hair dryer on a warm setting at close range for 15 minutes.
    • Day 3: Leave the token in your back packet and go about your normal day routine (sit on it).
    • Day 4: Place the token freezer (to simulate it being left out in the cold) overnight.
    • Day 5: Take it to meetings and fidget with it (in the on state if applicable). If it has keys or buttons, poke at them. Mildly flex it. Or, if you watch TV/videos, play with it while you veg-out.

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

The more cordial the buyer's secretary, the greater the odds that the competition already has the order.