Two Factor Authentication Systems? 69
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 (Score:5, Insightful)
What you might ask
But you know your system and requirements best.
Think bank cards (Score:3, Insightful)
Re:Can weaken security? (Score:4, Insightful)
Re:Two-factor Coming to 1 Million Paypal Accounts (Score:4, Insightful)
Smart cards (Score:5, Insightful)
There are several providers of smart cards for use as a second authentication factor. The one I'm most familiar with is ActivCard [activcard.com]. 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.
On the flip side (Score:3, Insightful)
Simple 2-factor authentication solution... (Score:3, Insightful)
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... (Score:3, Insightful)
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
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.
Re:Couple of choices that I remember (Score:2, Insightful)
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.