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)!
kerberos
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
If I'm not mistaken, most if not all of what you are looking for is already in OpenBSD. Speaking of which, the new 3.0 release is due December 1st...
There *is* an ACE/Agent for linux, and it works a treat. there's some source too, and an apache client.
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.
One other company providing this kind of solution is ActivCard.
They provide standard X9.9 tokens, authentication libraries (not open source, but you can integrate that into any server) and RADIUS server.
More important is that they also allow an easy migration between Token and smartcard, so that when your company wants to move to smartcards (for PKI for instance), you can migrate your population of token users.
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:
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.
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.
* As is generally the case, my opinions do not reflect those of my employer.
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.
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
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.
Fully licensed blockchain psychiatrist
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.
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
provides the use of SecurID tokens, but the software is written by Lucent. The application was created to work with Datakit networks, but it has evolved over time to also work with TCP/IP devices using ACE (RSA protocol), TACACS, TACACS+ and RADIUS.
I have heard that they have a newer version that runs on Linux as well as HP-UX.
You probably will not find it on their website because it is not one of their everyday use applications, and it is rather expensive (on par with the costs of RSA ACE server).
All administration is command line driven, but they also are supposed to have a web-based interface with the newer version. We had a Korn shell tool that someone had written for calling the command lines. I decided to write a curses-based app to provide an interface for our admins to use the application wthout knowing the command lines.
NAC does have a curses-based app that is similar to sdadmin on RSA, but I think both are quite ugly and unusable. I have not played with the RSA web interface yet.
On the other hand, RSA does provide a C and Tcl API so that you can also write your own interface. I have worked with this, but they do not provide enough APIs to output/update all of the data in the Progress database.
Most of the problems in security appear in a. interfaces of individually provably secure algorithms b. improper implementations of algorithms that you could prove secure otherwise. (Look for Dan Boneh's paper on fault injection attacks or on "textbook RSA implementations" for some easy, entertaining reading on this.) PS I work on mainframe security at IBM. In order to break ANY solution suggested by designers, we need to check maybe the first three interfaces in any proposal. 99.9% of the time this is enough to disqualify the proposal.
I know this because I've seen the source code, and I've hacked around in it during my last job (I made a PAM module for it).
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!).
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.
Paul Gillingwater
MBA, CISSP, CISM
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.
At this time, I don't want to recommend one vendor over another, but I'll just name them and highlight the differences.
CRYPTOCard: Used to be much more flexible (open source wise) than it is now. They no longer provide implementation details, but you can find them. Their current tokens implement the same things their old ones did. These tokens allow you to enter arbitrary length challenges.
PassGo: aka SNK/4. Pure challenge response, no synchronous mode. The least flexible of all the tokens, but still valuable. Many (some?) of the *BSD's have support for these "natively".
ActivCard: Definitely the most flexible of all the X9.9 tokens. The algorithm is published and could be easily implemented, modulo the patent problem. It wouldn't help you to implement it though, as you need their toolkit to extract the keys from the tokens or to reprogram the tokens.
Secure Computing: 3 different token models, probably as good as activcard but more open.
Vasco: They have 4-5 different models. I don't know anything about these tokens (yet).
Between PAM and radius, you can integrate these tokens into almost any environment. I will be writing a PAM module soon (if you want one "now" check out pam_smxs). The one environment where these aren't sufficient is krb5. I plan to get these devices working with heimdal in the future. (They already work with mit krb5.)
Download freeradius and look at the included x9.9 docs for more info.
Tokens are a good way to go but do be aware that you will have new problems where old password related problems used to live. For example, where there were dictionary attacks on the passwords there are now protocol or DOS attacks on the RADIUS server itself. Overall though, tokens solve more problems than they create.
My experience with a moderate-large scale (200 tokens) SecureID roll out was mildly negative. We had bad versions of the SecureID fobs that kept having their clocks desynchronize with the ACEserver. To be fair, newer tokens seem to have fixed this and a co-worker hasn't had a desynchronization in a year. The TCO of SecureID seems high as you have to _lease_ the tokens, pay programming/setup charges, purchase the ACEserver and related support, and then send the devices back to RSA when your lease is up. Gak.
As for CryptoCard, they are my choice. You actually _buy_ the token and they have field-replaceable batteries. As mentioned in previous posts, the algorithm is FIPS standard and gives you flexibility on potential uses of the token (particularly the RB-1 challenge/response token) and if you don't mind a little elbow-grease, you don't even need to buy their software.
I must warn you, though, that while the KT-1 keyfob tokens are cosmetically da bomb, I had significant problems with them. Being the "keyring" model it is, the KT-1 lacks the keypad the RB-1 has. This causes a couple of problems:
1. Entering the PIN requires the user to wait for the individual digits of their PIN to roll by on the screen and then press the single button on the fob to select that digit. Besides being very slow, I found it to be a potential security risk: because of the time involved entering the PIN, users limit their PINs to short sequences made up of ones, twos, and threes (112, 311, 111, etc). While the length of the PIN can be mandated through CryptoAdmin, you cannot mandate PIN quality (Mandatory 5 digit PINs? Users choose 11111, 12111, etc )
2. The "synchronized" mode of operation never worked well for me. When operating in this mode, the token and easyRADIUS server attempt to stay synchronized so that the user does not have to enter the challenge. The token will already know what the next challenge is supposed to be and issue the proper response. If the user mis-types the response then both the backend server and the token are supposed to be smart enough to proceed to the next challenge. In practice this never worked for me on either the RB-1 or KT-1 tokens. On the RB-1 it's not a big deal, you enter the challenge manually using the keypad and the card is re-synchronized, but without a keypad, the KT-1 is useless. While you can enter the challenge manually on the KT-1 using the single button, it is such a tedious process that it quickly becomes impractical. I ended up having to re-initialize the KT-1 (which has to be done using a specialized piece of hardware) to get it re-synced. This was with the older 4.x versions of CryptoAdmin, this could be fixed in 5.x but I haven't used 5.x.
While the KT-1s have their problems, the RB-1 is great. You can either initialize them manually through the keypad (which is a pain, but not overwhelming) or purchase the special initializer which worked very well. I never had a problem with the RB-1 but, to be fair, I only had 35 deployed cards. CryptoCard support was good (get past first level) and their on-staff Geeks knew their stuff and helped me out.
Well, I have to go. Hope this helps.
It is somewhat similar to the CRYPTOCard solution. It has a modem/crypto PCMCIA card that contains a user certificate, and it provides authentication with a User PIN.
It's not really useful even if you only want dial-up authentication because of the prohibitive price. The only reason you would deploy this solution is because you are the military or you are the government and you need a really strong crypto solution that already has NSA approval.
Dude, it's a spam response to any story. I agree with you.
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).
chongo (was here)
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%.
chongo (was here)
You want to know about the future of two-factor authentication? Go to www.authenex.com. Everyone in this space wants to be just a little cheaper than SecurID. Big deal!
These guys are whispering prices at trade shows that are approach an ORDER OF MAGNITUDE cheaper, baby. No application need go without strong authentication. These characters are running around saying things like this in their product literature:
"Most provocatively, Authenex technology can be massively distributed for quick adoption. The A-Key is low-cost enough to be given away for free in consumer applications . . . "
Incredible!
Kid Sumatra
I saw the releases but no price list - can you give us the price data?
Peter