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

Comments

RFQ

[chris_mahan]

RFQ to vendors. Let the CIO compare the proposal. Don't do his job. He's not cutting you a slice of his salary.

What you might ask /. is what to put in the RFQ together.

But you know your system and requirements best.

Re:RFQ

[QuantumG]

because he's lying. He doesn't have a job, or a CIO, he's a kid in his parents' basement submitting to Slashdot.

Can weaken security?

[molo]

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

Re:Can weaken security?

[RandomJoe]

We use the same RSA/Cisco setup where I work. And no, you don't have to enter any other numbers. A few people still have the hard tokens, or key fobs, and they do have to enter the number plus pin. With the soft token, you can open it up in one window and see the same sort of numbers, but they are evidently fed into the VPN client automatically. All I enter is a 4-digit numeric PIN!

Re:Can weaken security?

[QuantumG]

Yeah, that's stupid. RSA are right to offer it as it is appropriate for a desktop contained in a secure office facility somewhere, but it is not appropriate for a laptop.

Couple of choices that I remember

[emag]

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.

Re:Couple of choices that I remember

[Ararat]

1. If your network runs in the clear, with no network crypto protecting your connection, you've always got a potential risk of session hijacking, let alone more elaborate schemes to subvert the an array of networked authentication servers. The connection between an RSA Authentication Server and it various application-based ACE Authentication Agents that report to it is encrypted, but that doesn't protect other network links, nor the integrity of the TCP/IP session itself.

2. Neither CryptoCard, nor any other OTP vendor, can "emulate" the RSA SecurID's time-synchronized OTP generation, which continually generates a new OTP -- valid for only a minute or two -- every 60 seconds. RSA still has patent protection on this mechanism.

3. I don't know how dated your information about a vulnerability in a domain of multiple authentication servers is, but it seems likely that it dates from the ACE/Server 5.X family, back when RSA used a master/slave architecture. The crux of the problem -- which, to a lesser degree, still exists in RSA 6.x Authentication Managers -- lies in the definition of simultaneity, and the inevitable impact of latency on even "real time" network connections. Typically any effective attack -- which would ring alarms and be logged as a dangerous event as soon as the network was live -- would entail breaking at least two network connections, to isolate one of perhaps several networked authentication servers.

Bringing down multiple network links is no trivial task. There are also additional defenses available within most RSA Authentication Managers (aka ACE/Servers) which can turned on to make it more difficult to exploit a short-term network disruption with this sort of attack.

4. RSA Authentication Managers have two standard defense mechanisms which make this sort of race attack difficult without an attack that breaks both the primary and secondary network links between the servers. The first lies in the ACE Lock Manager (LM), a mechanism which effectively claims an account when an initial authentication call comes in.

If two authentication calls with identical credentials are received by an authentication manager within a very short period of time -- the default is 2 seconds, but it can be increased by the local ACE admin -- the authentication server will reject both authentication requests and request a new SecurID passcode from each user. In this, the LMs rely upon the ongoing distribution of database changes, which upgrades all the networked authentication servers every 100 seconds.

5. In addition, the Lock Manager, when it first receives a new authentication call, fires off a "real-time" message -- to each of its remote replicas -- which identifies the SecurID, by serial number, and notes how many token-codes it has generated since it was initialized at the RSA factory. (Using this metric avoids any server time-skew issues.) Each LM "remembers" all the token-specific metrics it has received for about ten minutes.

A new authentication call, from that token, will be accepted by one of the replica authentication servers only if the number of SecurID OTP cycles used to generate a specific token-code is greater than the count previously noted in the ongoing message traffic among the LMs. In this, the LMs act like a "pre-replication" system, distributing an exclusive claim on a specific token-code, from a specific SecurID, well ahead of the routine database replication.

6. The LMs use a "full-meshed" network topology. Each primary/replica transmits its token-specific lock-down messages to every other RSA authentication server in "real time" -- or at least as close to real-time as possible.

Think bank cards

[redelm]

Something you have PLUS something you know. One without the other is no good. Neither needs to be extremely strong. A number of companies make "smartcards" that plug into kbds, USB devices and PCMCIA cards. Use them with "PINs"

easy.

[croddy]

just encrypt the usernames. now you can leverage your existing authentication to move forward with a two-factor security plan!

See this article for pointers

[embobo]

http://www.smallbusinesscomputing.com/webmaster/ar ticle.php/3498116

It gives pointers to various offerings, including one-time passwords, hardware tokens, smart cards, and biometrics.

Two-factor Coming to 1 Million Paypal Accounts

[Anonymous Coward]

Two-factor authentication was a big part of the recent eBay-VeriSign deal. The headlines all mentioned eBay buying VeriSign's payment processing unit for $370 Million. But the agreement also calls for eBay to buy up to 1 million two-factor authentication tokens from VeriSign for use on Paypal. eBay will start rolling out the two-factor authentication tokens to Paypal and eBay users in 2006, including marketing and security programs designed to "promote customer adoption."

This is significant, since you have a lot more phishing attacks targeting Paypal and eBay than the major banks these days.

Re:Two-factor Coming to 1 Million Paypal Accounts

[QuantumG]

It really won't stop phishing attacks. The phishing site will just act as a man-in-the-middle between the customer and PayPal. There's nothing you can do to prevent this except educating users not to click on links in their email.

Smart cards

[swillden]

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:

• Store public/private key pairs and certificates for strong web authentication, e-mail signing and decryption, PKI-based login, etc. Most cards can even generate the key pair on-board so that the private key *never* leaves the card, for when non-repudiation is valuable (signatures, mostly).
• Store username/password pairs for situations where one-time password or PKI authentication isn't workable. Done properly, it can be arranged so that cardholders never need to know the passwords, which are large, randomly-generated and changed automatically and frequently. That makes password-based systems nearly as secure as one-time password or PKI, but doesn't require fixing all of the apps.
• Store biometric templates to allow a third authentication factor to be deployed without a central database of biometric data. Note that, IMO, biometrics are highly overrated as a security device for logical access control. Still some people want them, and smart cards can help make them more manageable.
• Provide other services, like electronic cash for the cafeteria, etc.

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.

A few pointers...

[eldub1999]

First, two-factor authentication is pretty much two-factor authentication. There are moderate differences in the various forms, but that is usually not the driving factor.

The biggest and most overlooked issue is the requirement for client-side software and drivers. The various OTP solutions (SecurID, etc.) are zero footprint. They can be used from any computer. If portability is as imporant as strong authentication, you should consider an OTP solution.

Smartcards and biometric devices require drivers at a minimum. Most require some type of middleware. This means you will have to manage a software deployment and the devices can only be used from systems that have the software installed.

Smartcards provide crypto, which can be leveraged for SSO, secure mail, etc. but by far, most of these projects succeed or fail based on the ability to actually deploy and use the solution.

On the flip side

[QuantumFTL]

As with all other so-called "security" schemes, it comes down to trusting the luser. 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."

Re:On the flip side

[psykocrime]

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.

One Time Password by Mobile Text

[antlope]

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.

vasco ?

[ncostigan]

one of the largest players, at least in europe, for 2 factor is vasco security (belgium?)

my bank (SEB in sweden) has been using them for years.
the system is pretty easy to use. you don't need a CS major to work it. /nc

PortWise

[pehag]

check out PortWise, it will give you one solution for OTP with lots of different authentication channels like Blackberry, Mobile Text, Mobile Token and so on. www.portwise.com

PassGo

[petegc]

I work for a company called PassGo Technologies. We have a two-factor authentication system called Defender that is fully integrated with Microsoft's Active Directory. All of the administration for the product is performed using the standard "Users and Computers" interface and all of Defender's information is stored in AD. As fas as I am aware, ours is the only two-factor authentication solution to provide this level of integration. Defender can provide strong authentication to VPNs, SSL VPNs, UNIX devices, NASs, firewalls, Microsoft desktops and Citrix products as well as any device that supports RADIUS. We support token types from a large number of manufacturers including Vasco and ActivCard. Contact me if you need any further information: Phone: +44 1460 258317 Email: pcooke@passgo.com Web: http://www.defender5.com/

Simple 2-factor authentication solution...

[cr0sh]

Probably one that violates half-a-dozen patents, but is fairly easy to implement.

• Something you have
• Something you know

The second piece is simple - this is your password, just as it always has been. The second piece is not as simple, but not as hard as you think.

First, determine (or guesstimate) the average number of logins a user will do in a day to your system (whatever it is). Let's suppose it is three times a day (that may be a ridiculously low number, I know). Take that number, and multiply it by the number of days that you want to allow the use of "something you have" - let's say 30 days (or approximately 1 month). So, there you have 90 unique instances. Multiple that number by something I will call the "secure factor" - that is, the number of "somethings I have, to type in" - let's say in this case "4", for a total of 360. Take the square root of that and round up to the nearest whole number (in this case, 19), square it again to get your "number of values" - or in this case, 361.

Now, have your system generate 361 keyboard typeable characters and store them as a string in the user's login profile. Present this list to the user as a grid of numbers (in this case, a grid 19x19), marked off along the X-axis by letters, and the Y-axis by numbers. For a website this system would be VERY easy to implement.

When the user updates their password (which expires each month), they get a new grid of numbers to print out and keep with them. When the user logs in, the system presents a challenge to them for them to type in as part of thier login procedure - in our case, 4 "secure factors", like "A7 D9 A18 E10" - and they would have to type those characters from their grid into the provided area. The system would then take this, check it against what it has stored in the user's login profile, and if those numbers match, the login matches, and the password matches, the user is allowed access. Those numbers used are "marked off" as used in the user's profile, and a different set is picked on the next login. When all sets are used up, the user is prompted to change their password, thus generating a new set for the user as well (with instructions to throw away the old set). This system should allow for 3 logins a day for 30 days, or a shorter combo which expire quicker because you run out of values (longer combos will expire on the password expiration).

Thus, essentially, the "what you have" becomes a grid one-time-pad, generated when the password for the user is updated. For this system to be truely secure, the grid should be delivered over a secure channel (in the case of a web server, SSL) when it is generated. Other issues to think about is what to do if someone is trying to guess the one-time pad (maybe they have a scrap of it?) - maybe flag the account on a wrong attempt and have the user update the password? You would also need to think about what to do if the user has lost the pad.

All in all, this solution or something similar could be pretty robust, fairly compact (if you make the printed OTP compact), and portable across all systems. Plus, it is fairly easy and cheap to implement (and train for). However, as I cautioned in the start, it is probably a patented method, but I think such a system is so obvious I wouldn't be surprised if there existed a PEAR (PHP) or CPAN (Perl) module for it...

Re:Simple 2-factor authentication solution...

[csirac]

I'm not sure what your point is. I was just clarifying that the eavesdropper could not learn the contents of the user's OTP card in the way you described.

Whilst I don't pretend to have the knowledge of even a first year undergrad specialising in cryptography, I have studied basic cryptographic techniques as part of my EE degree, and my understanding of the term "one time pad" is that it describes Alice and Bob both being in posession of the same list of arbitrary sets of data which can be utilised as secret keys. It just avoids transferring the key itself in message exchange, since both authorised parties already know it, reducing the chance of the eavesdropper reverse-engineering it. The only way an eavesdropper can learn it is by physically stealing the pad and making a copy. The poster's idea of printing the "pad" from the webserver creates a gaping hole, but that's beside the point.

Additionally, the OP's idea is susceptable to having the OTP card being copied and used /without knowledge to anyone/, whereas a list of one time passwords crossed out in sequence - well, at least the authorised user would notice their passwords are "out of sync" next time they go to use it, but then again if the attacker can copy the pad then he can also cross off a couple of passwords on Alice's behalf before she next uses the system without her noticing too.

Of course, you already knew this. I'm just wondering why you are clarifying the role of OTP to me.

The issues you raise are valid, and I don't think the poster thought his matrix was at all special cryptographically - just that it was a compact way to store 361 items of OTP information.

The OP thinks his idea is great because it's much better than simple user/pass authentication; but in reality we both know security has many more issues than this thing solves, the only benefit of his system is that it reduces vulnerability to keyloggers and weak passwords.

You're right, it is bad to replace a crappy system with an only slightly-less crappy one at the expense of a false sense of security, but I can see some merit to his idea for a very limited set of applications where the only alternative is traditional user/pass authentication on its own. Many finger-print scanners are laughably easy to fool with sticky-tape: but they're still used in the real world for convenience, not security applications.

Consider WiKID - FD: I work there

[nowen]

Did you consider WiKID Systems?

Available in both open (https://sourceforge.net/projects/wikid-twofactor/ ) and closed source (http://www.wikid.com/ versions. Closed source supports wireless devices such as Blackberries, Palm, PocketPC J2ME. Unlike certs, there is no need to manage white & black lists (CRL) etc. Unlike RSA soft tokens, the PIN is stored on the server and communication between the token and the server is encrypted asymmetrically. If the token is stolen, the PIN must be checked at the server allowing lock-out after an admin set number of attempts. Open sourced plugins are available for PHP, Java, COM/IIS, Citrix, C++, SugarCRM, etc. with more on the way. Token roll out can be completely automated via ASP scripts using trusted LAN credentials.

In terms of evaluating based on financial, relative security and operations issues you might want to read this, which I wrote for WiKID: http://www.securitydocs.com/library/3048. A cleaner costs analysis between a hardware tokens such as RSA and WiKID is here: http://www.wikidsystems.com/features/lessexpensive .