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! :)"
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
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.
Unfortunately in today's climate, this seems to be a losing proposition. "Something you have, and something you know" becomes "Something you can lose, and something you can forget."
Or worse yet, "Something that can be removed from your body with a saw;" in the case of biometrics. This is why biometrics don't appeal to me... if somebody wants my id with a password or smartcard, they don't have to do serious physical damage to me to get it (granted, they might anyway just to be malicious) but with biometrics, they *have* to cut off your thumb, or pop your eye out or what have you. Thanks, but no thanks.
// TODO: Insert Cool Sig