Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Strong Token-Based Authentication w/ Open Source Software?

Cliff posted more than 12 years ago | from the proper-security-access-is-required dept.

Security 87

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

cancel ×

87 comments

Sorry! There are no comments related to the filter you selected.

Let me get this straight... (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2512336)

The worst terrorist attack in recorded history occurred on September 11th, and now we're involved in a WAR against Islam and you people have the gall to be discussing token-based authentication with open source software???? My *god*, people, GET SOME PRIORITIES!

The bodies of the thousands of innocent civilians who died (and will die) in these unprecedented events could give a good god damn about token-based authentication with open source software, your childish Lego models, your nerf toy guns and whining about the lack of a "fun" workplace, your Everquest/Diablo/D&D fixation, the latest Cowboy Bebop rerun, or any of the other ways you are "getting on with your life" (here's a hint: watching Cowboy Bebop in your jammies and eating a bowl of Shreddies is *not* "getting on with your life"). The souls of the victims are watching in horror as you people squander your finite, precious time on this earth playing video games!

You people disgust me!

Re:Let me get this straight... (-1)

trollercoaster (250101) | more than 12 years ago | (#2512342)


Beautiful!!!

Re:Let me get this straight... (-1, Offtopic)

override11 (516715) | more than 12 years ago | (#2512374)

You would rather have the whole world throw their hands up in the air and sit home???? Man, if you had a clue how many horrors happen around the world every day, you would never leave your bedroom. Its people who are strong and know that they have to move on that keep this country and its economy moving. The future is something created by the present, and if you think that because of this event you cant have fun anymore, I feel sorry for you. Getting on with your life means doing what you have done in the past. Because I play video games does not mean I am not aware of what happened. *yes, ranting and incoherent, but this anonymous coward needs a smackdown*

Re:Let me get this straight... (-1, Offtopic)

override11 (516715) | more than 12 years ago | (#2512385)

Screw moderators. -1 offtopic my butt, its responding to a person who needed a response

Re:Let me get this straight... (0)

Anonymous Coward | more than 12 years ago | (#2515450)

Dude, it's a spam response to any story. I agree with you.

pF (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2512352)

p50+ the fr15+!

Here ya go... (3, Troll)

FortKnox (169099) | more than 12 years ago | (#2512376)

... a link [google.com] full of answers.

Talk about standard "AskSlashdot"...

Re:Here ya go... (0)

Anonymous Coward | more than 12 years ago | (#2512659)

Talk about standard Slashdot asshole response.

Come on, it's obvious this guy has already done his homework - I bet he even used a search engine. What he's looking for is discussion from people with experience and insight with the technologies involved. If all you know about is typing words into Google then maybe his question wasn't aimed at you.

Re:Here ya go... (0)

Anonymous Coward | more than 12 years ago | (#2512910)

Talk about standard Slashdot asshole response

I'm not a "standard Slashdot asshole". I run WinME at home, happily, and write Java code at work (hating perl for large webpages). I'm what you'd call a "unique asshole", thankyou.

-FK

Re:Here ya go... (0)

Anonymous Coward | more than 12 years ago | (#2513062)

Hmm.

You run windows, like 90% of the world.

You're a JSP/Servlet monkey, like 99% of ex-VBers.

Unique doesn't really apply here...

Re:Here ya go... (0)

James Skarzinskas (518966) | more than 12 years ago | (#2513816)

Oops! Unique? Your using cliche garbage like Windows ME, and JSP and you expect us to call you 'unique'? You sure don't deserve the title. How about, "common fool"? :)

1st p0st! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2512382)

13st p0s7 m07h3rfuqk3r5!

Well (3, Informative)

mwalker (66677) | more than 12 years ago | (#2512389)

These guys [v-one.com] 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 [baltimore.com] for about ten grand.

Re:Well (0)

Anonymous Coward | more than 12 years ago | (#2513247)

dont use the baltimore toolkit...it sucks royally.

Re:Well (1)

Technik~ (87292) | more than 12 years ago | (#2513302)

They aren't totally OS-unfriendly but they also aren't inexpensive. FWIW, they do make use of Red Hat in their Smartguard [v-one.com] appliance and their field guys are Linux saavy.

- technik

i like the dallas ibutton (2, Interesting)

dfelznic (8812) | more than 12 years ago | (#2512396)

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

Re:i like the dallas ibutton (2)

baptiste (256004) | more than 12 years ago | (#2514079)

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 [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 (2)

the_2nd_coming (444906) | more than 12 years ago | (#2512409)

they have a few sub projects that are working on Authentication systems. one or 2 are token based I think....give it a look

Re:Look at DotGNU (3, Informative)

the_2nd_coming (444906) | more than 12 years ago | (#2512422)

damn...hear is the link [dotgnu.org]

iButton (5, Informative)

gwaihir (101320) | more than 12 years ago | (#2512412)

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

Re:iButton (3, Interesting)

gorilla (36491) | more than 12 years ago | (#2512498)

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.

Re:iButton (2)

baptiste (256004) | more than 12 years ago | (#2514091)

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 [slashdot.org]

Re:iButton (2)

gorilla (36491) | more than 12 years ago | (#2514222)

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.

Re:iButton (0)

Anonymous Coward | more than 12 years ago | (#2512614)

Yeah, go ahead and order one, or 500 of em. You'll never see them. I ordered 500 of them 8 months ago, and have yet to actually see them. They claim a manufacturing problem.

Re:iButton (0)

Anonymous Coward | more than 12 years ago | (#2512781)

What are you talking about "never see them"??? There are millions upon millions of them in use globally!!! Have been for the past several years!

ibutton purchase contract terms unacceptable (3, Interesting)

Brian Ristuccia (2238) | more than 12 years ago | (#2513071)

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.

Re:ibutton purchase contract terms unacceptable (3, Insightful)

StenBoltz (50976) | more than 12 years ago | (#2513407)

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.

Ben

Re:ibutton purchase contract terms unacceptable (2)

Dwonis (52652) | more than 12 years ago | (#2515290)

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 (3, Informative)

jmauro (32523) | more than 12 years ago | (#2513187)

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.

blah (0, Interesting)

LWolenczak (10527) | more than 12 years ago | (#2512449)

kerberos

I would hate to smash your small world (2, Interesting)

LWolenczak (10527) | more than 12 years ago | (#2512859)

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.

Re:I would hate to smash your small world (3, Informative)

dmadole (528015) | more than 12 years ago | (#2512932)

I hate to break it to the previous poster, but it may not be exactly what they need. Kerberos is good, but: 1. It doesn't work well with non IP-network situations, i.e. dumb-terminal applications, PPP dialup authentication, authentication over the phone (touch-tones) 2. As an extension to the above, it does not integrate well into legacy platforms and applications. Most things that can do user ID and password can do text challenge/response pretty easy. The CRYPTOcard can also be used as a OTP generator (in event-syncronous mode, with care), which eliminates the need for the challenge even. 3. Kerberos is token-based internally, in a way, but the authentication with the user is still passwords. You still need to deal with lost/compromised/*SHARED* password issues. The biggest advantage IMO of hard token systems is that the user cannot duplicate the key, even intentionally. Kerberos is really an encrypted-password based single-singon system, not exacly token-based authentication. It does not solve all problems, especially when behind RADIUS, which is one of the poster's requirements.

Re:I would hate to smash your small world (0)

Anonymous Coward | more than 12 years ago | (#2513024)

Another option is Tacacs+ based services. It has support for all three A's (Authentication, Accounting, and Authorization), it is TCP based,
and it integrates well with CISCO equipment. That much said, the freeware version of Tacacs+ doesn't do Accounting very well...it's best support is for Authentication.

What about Diameter? (2, Interesting)

frascone (466844) | more than 12 years ago | (#2512458)


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? (2, Interesting)

isj (453011) | more than 12 years ago | (#2512520)

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.

whois really on the line? (-1, Redundant)

Anonymous Coward | more than 12 years ago | (#2512484)

We're [scaredcity.com] all for (as you might be able to guess) using some GNU systems to authenticate/verify users, etc... So far, our best answer is to keep confidential/private inf. OFF our web servers. That's working well for us.

Meanwhile, don't forget to enter our web address [opensourceworks.com] giveaway. Includes a year's free hosting. Just in case you need somewhere to hang your hack when the GNU millennium kicks in.

fud is dead (that's maybe, & then only maybe in 18 U.S. states, as the lamo fuderal gov't. has conceded, & decided to take IT up the .asp for another decade or so).

CryptoCard leaves a little to be desired (3, Informative)

lactose99 (71132) | more than 12 years ago | (#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.

Re:CryptoCard leaves a little to be desired (0)

Anonymous Coward | more than 12 years ago | (#2514360)

I think you're using an older version of easyRADIUS. The newwer version are based on a JDBC backed which you shuold be able to query all nice like.

SecurID clone (3, Insightful)

austad (22163) | more than 12 years ago | (#2512638)

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.

Re:SecurID clone (1)

fender0011 (153195) | more than 12 years ago | (#2513095)

  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.

This definately ain't... (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2512648)

The First post! So you don't need to read this.

OpenBSD (0)

Anonymous Coward | more than 12 years ago | (#2512700)

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

ACE/Agent for linux (0)

Anonymous Coward | more than 12 years ago | (#2512767)

There *is* an ACE/Agent for linux, and it works a treat. there's some source too, and an apache client.

Re:ACE/Agent for linux (1)

drsoran (979) | more than 12 years ago | (#2518761)

The problem is that you need to link your applications against a closed source library (sdiclient.a). Now, if you're willing to pay ($15k-$30k), RSA Professional Services would be happy to compile a client for whatever platform you want. Again though, IMHO it's plain out and out rape to charge $40-$60 per token and then thousands of dollars for the ACE/Server and then on top of it all the entire thing is a closed source mess. Try setting up local authentication with it. Their "solution" is to replace your shell with sdshell and your real shell is spawned from that program after you enter your passcode. Good luck if you want to change your login shell though since you'll need to contact the ACE administrator. Heck, it gets worse if you want to login to X. Again, their solution is sdshell with a shell script wrapped around it that gets put into your X login scripts. Personally, after using the securid products for the last 3 years they've been nothing but a major pain in the ass.

CRYPTOcard is as close as it gets (3, Informative)

dmadole (528015) | more than 12 years ago | (#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.

NetBSD Net/Radius port, OpenBSD BSD Auth, Hackery (2, Informative)

Paul Doom (21946) | more than 12 years ago | (#2512793)

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

CryptoCard is basically SNK-004 (2)

Nonesuch (90847) | more than 12 years ago | (#2512812)

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 [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 (1)

dmadole (528015) | more than 12 years ago | (#2512886)

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.

SafeWord for Linux from Secure Computing (2)

Nonesuch (90847) | more than 12 years ago | (#2512850)

Secure Computing [securecomputing.com] offers SafeWord [securecomputing.com] , 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.

Re:SafeWord for Linux from Secure Computing (2, Interesting)

Ethan Butterfield (7481) | more than 12 years ago | (#2512985)

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.

DES, 3DES, and key length (3, Informative)

dmadole (528015) | more than 12 years ago | (#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.

wrong attempt lockouts let anyone lock any account (3, Insightful)

Brian Ristuccia (2238) | more than 12 years ago | (#2513116)

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

Re:wrong attempt lockouts let anyone lock any acco (1)

lactose99 (71132) | more than 12 years ago | (#2513429)

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.


Re:wrong attempt lockouts let anyone lock any acco (1)

monkeydo (173558) | more than 12 years ago | (#2513432)

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.

ActivCard: Another solution (0)

Anonymous Coward | more than 12 years ago | (#2512870)

One other company providing this kind of solution is ActivCard [activcard.com] .

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.

S/Key (1, Informative)

Anonymous Coward | more than 12 years ago | (#2512899)

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.

Re:S/Key (provably secure) (0)

Anonymous Coward | more than 12 years ago | (#2513856)

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 [stanford.edu] attacks or on "textbook RSA implementations" [stanford.edu] 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.

Is it 2 Factor Authentication? (2, Interesting)

Don Faulkner (138856) | more than 12 years ago | (#2512941)

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.

Re:Is it 2 Factor Authentication? (0)

Anonymous Coward | more than 12 years ago | (#2513961)

My understanding of the secureID token is that
it contains a secret specific to that token
along with a clock and hash alogithm. So it
really is a "something you know" (the pin)
and "something the fob knows" (the secret).

It's not at all "something you have".

Someone knowing both secrets could authenticate
as you (the hash and current time aren't secrets
as they don't differ between fobs).

Keep in mind that all the computer sees for any
of these authentication systems is bits. Bits
don't say where they came from.

To really implement "something you have"
you'd need some sort of Star Trek technology
to transport the fob to see it was really there.

And the fob would have to have some sort of
quantum properties forcing it to be universe
wide unique.

Perhaps not Star Trek, sounds more like D&D
and the one true key.

Re:Is it 2 Factor Authentication? (1)

Don Faulkner (138856) | more than 12 years ago | (#2514341)

So it really is a "something you know" (the pin) and "something the fob knows" (the secret).

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 (1, Informative)

Anonymous Coward | more than 12 years ago | (#2514183)

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

Re:SecurID token is not as precise as you make out (0)

Anonymous Coward | more than 12 years ago | (#2515054)

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

Indeed. And that makes ntpdate a powerful tool for evil on the ACE server...

Re:Is it 2 Factor Authentication? (0)

Anonymous Coward | more than 12 years ago | (#2514583)

securid, as you describe it, is NOT 2 factor. We can *assume* that the PRN (passcode) is observed in transmission -- this is one of the things we buy tokens for, ie, to protect against a password being observed and thus stolen.

The keyfob requires that you enter your pin along with the passcode. Thus it is observable and you are reduced to one-factor -- something you have.

There is a credit card version of securid where you enter the pin into the token (like cryptocard) which is 2-factor.

RSA ACE/Server (1)

nedron (5294) | more than 12 years ago | (#2512971)

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!

PKI vs. Tokens (1)

speedy1161 (47255) | more than 12 years ago | (#2513039)

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.

Re:RSA ACE/Server (1)

JonNoble (533804) | more than 12 years ago | (#2513109)

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

Re:RSA ACE/Server (1)

nedron (5294) | more than 12 years ago | (#2513338)

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.

Re:RSA ACE/Server (1)

JonNoble (533804) | more than 12 years ago | (#2514267)

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)

Re:RSA ACE/Server (0)

Anonymous Coward | more than 12 years ago | (#2513428)

The RSA algorithm has some security issues, you need to make sure that nobody ever gets ahold of a token and that traffic between teh user and the ACE server is encrypted.

For more information:
http://www.linuxsecurity.com/articles/cryptograp hy _article-2336.html

Strong, Tolkien-Based Authentication (3, Funny)

tswinzig (210999) | more than 12 years ago | (#2513165)

Is that like when Gandalf couldn't remember the phrase to open the cave door to the mines of Moria?

Secure Palm Pilot (2)

autocracy (192714) | more than 12 years ago | (#2513239)

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

The Lucent NAC application ... (0)

Anonymous Coward | more than 12 years ago | (#2513521)

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.

SecurID source code (0)

Anonymous Coward | more than 12 years ago | (#2514077)

Its main problem is that it's very open-source unfriendly: nothing is provided in source-code form, under any license...
It may be open-source unfriendly, but there must be a way to get the client source code under some sort of commercial license.

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

Try Connexitor from Symas (1)

PGillingwater (72739) | more than 12 years ago | (#2514390)

See http://www.symas.com.


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 (1)

Baptiste1 (533870) | more than 12 years ago | (#2514637)

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.

A Token survey (0)

Anonymous Coward | more than 12 years ago | (#2514644)

I am the author of the support for these devices in freeradius. I'll limit this very short blurb to X9.9 tokens (which all of them are, except securid).

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.

My experience with CryptoCard (positive!) (0)

Anonymous Coward | more than 12 years ago | (#2514648)

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.

Re:My experience with CryptoCard (positive!) (0)

Anonymous Coward | more than 12 years ago | (#2514698)

[KT-1] you cannot mandate PIN quality

Yes, you can. You can make the PIN unchangeable by the user. When you issue the token you select a random pin or have them enter a pin which you (programmatically, not manually!!!) verify for quality. Your own pin-cracklib, if you will.

The "synchronized" mode of operation never worked well for me.

You have implemented it poorly then.

Re:My experience with CryptoCard (positive!) (0)

Anonymous Coward | more than 12 years ago | (#2523090)

Implemented it poorly? It's CryptoCard's implementation, not mine, so they implemented it poorly. Even their support couldn't get it to work.

Related technology (0)

Anonymous Coward | more than 12 years ago | (#2514821)

This doesn't really answer the question because it wouldn't be a viable solution, but here [rasp4secret.com] 's a RADIUS-based dial-up authentication solution. If you don't mind paying a fortune for a few 33.6K modems, that is. I only thought it might be of interest because it is the only such solution certified by the NSA to protected classified Secret information.

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.

CRYTPOcard DoS issue (1)

chongo (113839) | more than 12 years ago | (#2515877)

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

Re:CRYTPOcard DoS issue (0)

Anonymous Coward | more than 12 years ago | (#2516543)

But the DOS goes away with the Challenge Response mode!

All in all we like cryptocards. They could be better (more on that later), but they are nice.

Here's how we use the cards:
- If you think the cards is in sync, use the quick response.
- If that fails or you think the card is out of sync, use challenge response.

It works pretty well. Note that CR limits the choices of tokens you can use. The little keyfobs don't support it.

It did take some effort to get SSH to use CR under Linux. HINT: Use commerical SSH2 (note the license allows it's use under Linux)

It amazes me that the product doesn't come out of the box with an *easy* solution for ssh and local logins. IMHO, these are the two uses that most Linux uses *should* want (in addition to any custom ones they have per application).

Wish list:
- Work through the setup issues for SSH out of the box (of course we already solved that).

- Store more than one toke on a card

- Make the card optionally "beep" when keys are pressed.

- Make a version of the token that fits into the Palm M500 SD slot that supports CR.

- Provide a USB reader that after the pin has been entered lets you pull thye one time password from the token (and lets you push the challenge to it). Rationale, once the PIN is entered on the token, make it be really easy to use it. This is especially helpful if you want a less technical group of people to use these on a daily basis.

- Provide a smaller form factor for a token that supports CR. I can press buttons with a pencil/pen point.

I emailed CryptoCard with these issues and they said that their smart card addresses all of these. The basic issue is you can't use the smart cards standalone (need a reader and associated s/w with you which limits you in case of an emergency) and the PIN must go through some sort of software layer to the reader (which is a potential hole).

All in all, we're pretty happy with cryptocard.

P.S. If you really care about security, never use the software/palm tokens. They can be copied.

Re:CRYTPOcard DoS issue (1)

chongo (113839) | more than 12 years ago | (#2520756)

> But the DOS goes away with the Challenge Response mode!

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 (1)

chongo (113839) | more than 12 years ago | (#2515917)

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

A test of moderation (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2525808)

This post should be moderated down.

Authenex Alone in the Field for Price/Performance (0)

Anonymous Coward | more than 12 years ago | (#2526032)


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

Re:Authenex Alone in the Field for Price/Performan (1)

peterfcassidy (150995) | more than 12 years ago | (#2527293)


I saw the releases but no price list - can you give us the price data?

Peter
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>