Two Factor Authentication Systems?
HerculesMO asks: "I've been given a project to undertake that involves setting our internal network systems up to have two factor authentication. I need suggestions to take in front of our CIO that shows how the security model works, cost vs benefit/features, and the different options. At this point, the name brand is RSA and I'm pressed to find any others even though I've done looking around. We are open to biometric tokens as well, because they may be used for digital certificate signing for e-mails. Sadly, it has to integrate with our Windows 2003 Active Directory set up... it's not Linux, but I figure Slashdot readers can come up with lots of Linux security tokens that will work under Windows too, so please have at it! :)"
RFQ to vendors. Let the CIO compare the proposal. Don't do his job. He's not cutting you a slice of his salary.
/. is what to put in the RFQ together.
What you might ask
But you know your system and requirements best.
"Piter, too, is dead."
My corp just switched to a two-factor auth. Previously, things were based on the cisco VPN where the client had to have a certificate (but not an individual-per-client certificate). We then had to log in with our domain login and password.
Now we have switched to cisco VPN plus RSA software token. This is not any better. Now we have a certificate, rsa token, and then we enter a pin number, as short as 4 digits.
This has not improved security one bit, it has actually weakened it. If a laptop is stolen, the "piece you have" went with it. The software token doesn't provide any security over the vpn certificate. Then, the "piece you know", the PIN, is significantly weaker than the old piece you had to know, the domain password (which was a real password with moderately strict rules on complexity).
The whole thing is a counterproductive wankfest. Perhaps you can do it better, but this should be an example of what not to do.
-molo
Using your sig line to advertise for friends is lame.
You've got a couple choices if you want a token-based dual factor authentication scheme. Of course, there's RSA's SecurID that you already know about. There's also CryptoCard, which IIRC can emulate some of the RSA tokens, and has its own scheme.
Now, what's nice about SecurID is AFAIR it's the only token that does *time*-based auth (ie, the displayed number sequences change constantly as a function of elapsed time). However, there's a really ugly problem with their auth servers that we accidentally discovered trying to set up a replicated server for failover purposes. To wit: the servers only sync based on a timed (as opposed to event-based) schedule. So, in the normal course of events, you can sometimes reuse the same token (# stream on the hardware device) even though they supposed to be single use. This happens when you attempt to have both servers service requests, and login 1 uses server A to authenticate against, and login 2 ends up using server B to authenticate in a very short period of elapsed time. Server A hasn't had a chance to tell server B yet that it's already seen that particular number sequence, so B happily accepts it.
Now, the devious-minded can see a problem here... You can be sniffing a network connection, get the token, pin, and password from the network ("hey, we have these hardware tokens, why should we ssh/ssl/vpn?" or what annoyed me, "we can't use ssh key authentication, we *must* use password auth with this"), then DoS one of the auth servers, and attempt a login with the same credentials, hoping to get an alternate, not-yet-synced auth server. Bang, you're in (eventually). So much for the whole non-replayable 2-factor authentication thing.
I don't think this problem was ever solved satisfactorially (I've since moved off that contract), but you can "solve" it by only having a single auth server...
Unfortunately, I know a lot less about CryptoCard, since we went with SecurID ourselves and didn't find the warts until later.
Oh, yeah, good thing this is just windowss, as linux was ok, but Digital Unix and Irix were a bitch to get working with SecurID.
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
just encrypt the usernames. now you can leverage your existing authentication to move forward with a two-factor security plan!
This is significant, since you have a lot more phishing attacks targeting Paypal and eBay than the major banks these days.
There are several providers of smart cards for use as a second authentication factor. The one I'm most familiar with is ActivCard. Their stuff is reasonably good, and if it helps in your corporate environment IBM Global Services has a team that does a lot of ActivCard integration, so you can get plenty of support from a reliable provider (for a price :-) ).
IMO, smart cards are a better solution than SecurID tokens. They're cheaper, allow your logical authentication token to be the same card you use as an ID badge (and perhaps for door access) and can do a lot more things. They can act as one-time password generators, just like a SecurID (but guarantee non-reusability of the passwords, unlike SecurID, as mentioned by another poster) but they can also:
The major disadvantage of smart cards as compared to SecurID tokens is that smart cards have no display, so you need a smart card reader to use them. This means that, for example, you could use a SecurID to authenticate to a corporate web site from an Internet cafe, whereas you might not be able to attach a smart card reader to some random PC. As a partial solution, handheld, calculator-like smart card readers exist that can retrieve a one-time password from the card and display it on a screen. I say it's a partial solution because carrying two devices is less convenient than one SecurID. The cost of such a device, plus a card, plus a regular PC-attachable card reader all totals to something less than a SecurID token.
Disclaimer: I work for IBM Global Services, in the group that does smart card stuff, including ActivCard integration work, so I have some biases, but I also have a deep knowledge of the industry and, at present, I think the ActivCard product set is the best choice available, overall. Cryptocard has some good stuff as well, but it's not as complete or as mature, especially in the area of enterprise card management (issuance, re-issuance, revocation, etc. all needs to be integrated and automated, complete with automatic key escrow and recovery, etc.). Both ActivCard and Cryptocard support Linux and OS X, though ActivCard's support for Tiger isn't there yet, and Cryptocard's is, mostly. ActivCard also supports Solaris, including SunRay environments. IBM has some nice assets that we use to build customized solutions, but our stuff is focused more on multi-factor biometric authentication for physical security than logical security.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Combining SSL, username and password together with a simple One Time Password delivered by pager, mobile text (SMS) or even voice mail, gives good two factor authentication. Several companies provide good solutions that are of differing level of complexity to integrate.
Check out this link for more information on one time password authentication. I work for this company so of course I'm biased =) but its the best OTP service I've used. It will integrate fine with your AD or any other LDAP/SQL user source.
http://www.nordicedge.se/produkt_otp.shtml
The major reason why hardware tokens are not so popular in my experience is that people think they are clumsy to lug about everywhere. Even the keychain versions are annoying. Smart cards are great but you need a computer with a smartcard reader.
I think we'll be seeing more and more applications aimed at users mobile phones, for the simple reason that everyone likely to use an online service is also likely to have a mobile phone.
Most people are much more likely to notice a lost or stolen phone, than a lost or stolen token device...
Good Luck in your solution.