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?

[Raleel]

DOn't you have to enter in a number off the RSA token? At our company, we have a certificate as well, but we have to enter in a PIN + number off the token. that number changes every minute and more accurately represents the thing you have than the certificate.

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.

Re:Can weaken security?

[$mooth]

and then we enter a pin number

A Personal Identification Number Number? What's that exactly? Do you need those for ATM Machines?

Re:Can weaken security?

[platos_beard]

If a laptop is stolen, can't that "piece you have" be de-authorized? If not, there's hardly any point in having it.

Re:Can weaken security?

[Anonymous Coward]

Yes. And if you call in promptly, you're only liable for the first $50 worth of stolen nuclear secrets.

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.

Secure Computing SafeWord

[booch]

Secure Computing has what appears to be a very strong competitor to RSA's SecurID. Their SafeWord product is similar to SecurID, but appears to have some advantages. For one, it only generates tokens when you request it to. I believe it's cheaper too. It supports Active Directory. I've not used it, but their demo was impressive. And Secure Computing is a fairly good security company.

Re:Secure Computing SafeWord

[austad]

I used to think this was an advantage, but it is not. The reason is that if an attacker tricked a user into typing in their next few passwords, they could use it at their leisure, instead of having to use it immediately.

It's still more secure than a static password though.

Re:Secure Computing SafeWord

[booch]

Wow, excellent observation. I was just considering that it saved a lot of battery over the SecurID. But the time restriction for each token is sort of an extra factor in the authentication. (Although it's a pain in the ass when the SecurID tokens get out of sync.)

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.

Re:Smart cards

[Anonymous Coward]

I'd like to talk more about the topic if you don't mind. I added you to sametime, I'll hit you up if I see you on :)

Two-factor Authentication Conductor School

[DasBub]

"Two" means two.

"Factor" means factor. ...

This concludes your intensive six-week training course.

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.

Re:On the flip side

[QuantumFTL]

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

You said it, man.

P.S. It's this kind of thing that makes me want to vote libertarian, as maybe companies won't be as stupid as the government about such biometric identity...

Re:On the flip side

[Ararat]

I think the poor user gets a bum rap on this, and on many other aspects of the technology that gets laid upon them. It wasn't the users who stuck themselves with multiple passwords, of limited length, each of which can be typically cracked with a moderate amount of time on a password cracker.

It wasn't the users who, as passwords became more vulnerable, laid upon them these Draconian rules which mandate routine changes in all passwords, each to conform to some standard of sufficient complexity that guarrantees that they can't be remembered by mortal men. And it was us techies who, for a decade or so, piously lectured them that they shouldn't write down their passwords -- long after the number of passwords the typical user was expected to memorize had exceeded the number of phone numbers he knew by heart.

Pity the poor user! We gave him a Web brower that can't offer anything like the overt indicators of high risk or pending fraud that he uses to survive in the brick 'n mortar world. We gave him email encryption that you need a phd to understand, and a MS to use -- and the paranoid government kept insisting that he should only authenticate, never encrypt, and continually monkeyed with the standards to leave him unprotected. And this is not even to mention the blizzard of belittling comments from our self-righteous vendors, with their software products for which they disclaim all responsiblity yet are forced to provide daily patches.

Pity the poor user! He has to put up with management bean-counters too cheap to spring for an OTP token, typically the price of a modem, or even a scratch card of OTPs. Worse, he has had to put up with us security types mouthing cant about "user education" for years -- as if the victim is to blame for the poor tools and insecure protocols we created for his exploitation.

Consider the number of enterprises which still refuse to authorize the storage of personal passwords in a cryptographically secure vault for their PCs or PDAs. And those which still lecture him that he should not write down his 15, or 30, or 50 passwords on paper. Pity the poor user! He has to deal in reality, while all to many of the techie elite wander around with our heads in the clouds!

Re:On the flip side

[theLOUDroom]

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

I'd say this is why a great many security schemes fail: contempt for the user

Contrary to what many believe the computer is there to help someone do a job, not to be an impenatrable vault for information. Anything you do that makes things obnoxiously difficult fot the people who actually need to get work done will be circumvented by the "lusers".
This is because security incurrs a cost. The goal should be to minimize that cost while providing decent security, not to provide security with total contempt for those who will have to put up with it.


A decsision to implement "two-factor" authentication should weigh the costs assoscited with it's implementation, versus the additional security benefit. Once you start looking at what the actual security benefits are, you may decide to forget about it all together. In the end you only get two major things from adding a physical token:
-difficulty duplicating it
-obviousness of its theft

In the end, I recommend startcards. They're pretty cheap, very secure and they aren't tied to one specfic vendor.

They'll probably go with fingerprints though, as they probably don't actually need the level of security they're asking about, so they'll go for the whiz-bang factor.
You can tell by how he says:
We are open to biometric tokens as well, because they may be used for digital certificate signing for e-mails.
A smartcard could be used for the same thing and it would be more secure. Sadly, this is probably just going to be another episode of "security theatre".

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.

Sigh, netkey is the *real* answer

[DrSkwid]

The server asks you to hash a string.

You run a program locally (here's some) or incorporate it into your client in which you enter your password and it spits out the 5 digit hash. Tell the server what the hash was, it compares it to what it thinks you should have entered.

All very simple and works just fine over unencrypted links !

plan9 uses it for ftp access

Apache / Firefox also support something similar for HTTP Authentication - your password is md5'd with some salt instead of just being base64'd

that is all

Re:Sigh, netkey is the *real* answer

[arkanes]

Thats not 2-factor authentication, isn't new, isn't exciting, and already has better implementations (like SSH key exchange).

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

Nice Submission - "sadly"

[Gothmolly]

Sadly, it has to integrate with our Windows 2003 Active Directory

Why troll?

Re:Nice Submission - "sadly"

[jea6]

Sadly, it has to integrate with our Windows 2003 Active Directory
Why troll?

To get the article posted.

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

[Anonymous Coward]

I spent 10 minutes proving this to be cryptographically insecure, which is twice as much time as poster spent pulling this out of his ass.

Re:Simple 2-factor authentication solution...

[pyite]

Says the undocumenting Anonymous Coward...

Re:Simple 2-factor authentication solution...

[jurik]

This is insecure for three reasons:

• At every log in the user exposes some of the 19x19 grid, so an attacker can just eavesdrop until he has a fair part of the matrix and then keep trying to log in until he get only squares that he knows. This will take a fair amount of the attacker, but with a little patience he'll know alot of the matrix at the end of the month so he would prob. need (know half the matrix) ~2^8 to (know 1/4 of the matrix) 2^16 tries before succeeding.
     
• It's very susceptible to man in the middle attack, simply let the user connect to you instead of the server and get him to answer the questions from the server, and when authenticated, drop the line to the user and continue with your connection to the server.
     
• It's even more susceptible to phishing. Just keep letting him answer different queries in the square and make a lame excuse why the previous result couldn't be used (e.g. connection to DB temporarily lost, please try again :-P).
  

When you know a fair portion of the matrix simply try to log in until you get a hit in what you know of the matrix.

And that is not even taking into account that the user has to keep a 19x19 matrix secret for a month.

The morale is if you don't know crypto don't do it because this is even less secure than a pure password scheme because you give people a sense of security where there is none!

Re:Simple 2-factor authentication solution...

[csirac]

The poster said that each element in the matrix is only requested once.

So no part of the matrix is every repeated; the eavesdropping attacker can't do anything with learned matrix elements, because the system will never ask for those elements again.

Re:Simple 2-factor authentication solution...

[jurik]

Ok then do the following: Initate the log in 19x19 / 4 times and the system will be totally locked. Note you can't reuse unanswered request - problem easy for 1st year cryptology students, so left to the reader.

And the 2 other problems still pose a big problem.

Face it - the idea is crap. Don't fix a bad problem (passwords are weak) with crap - all you get out of it, is a system that stinks.

Re:Simple 2-factor authentication solution...

[csirac]

Yes, the idea is "crap" but the fact is it's a one-time pad. The attacker cannot gain unauthorised access in the way you described. The attacker can cause a Denial of Service, but they won't get access.

Re:Simple 2-factor authentication solution...

[jurik]

It might prevent a purely eavesdropping attack - at the cost of easy denial of service attack, but both phishing and man in the middle will work (very well at that).

And there is no one-time pad in the suggested solution. One-time pad is a (secure) encryption. There is OTP = One time passwords, which can be secure. The above would work I guess if you threw in

• SSL conenction at log on
  
• server certificate
  
• educated users that actually check the complete correctness of the certificate each time
  
• and a secure connection after log on (not necessarily encrypted, but one that can't be hijacked).
  

But given that solution, why use a 19x19 matrix and not just a normal list of 4 char one-time passwords?

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.

Re:Simple 2-factor authentication solution...

[cr0sh]

Note - I am the original poster...

I have read over all of the comments, and yes, they all have merit. I may not have made it clear, but I was hoping to get across the idea that both the delivery of the OTP and the entry of the factors from it would be done via an SSL (or other) secured method.

Since my knowledge of crypto is weak (as clearly demonstrated by the numerous and insightful responses), I am curious as to how, if the delivery of the OTP and entry of the factors is done via SSL, how a man-in-the-middle attack would succeed? I am not saying it isn't possible - I just want to understand how it is possible, the mechanics to set this up even with SSL in the way (and if this is so, then aren't all SSL secured sites just as vulnerable currently?).

Now, I will concede that the need for the user to print out the pad is a point of vulnerability - in an office environment, one could see that the information could be sent over the network and captured that way, or the information might be stored on the hard drive of the printer/copy station, or any other number of ways, and in the home environment (as well as the office), you could in theory have loggers (put in by spyware or whatnot) capturing data sent to the printer.

As far as phishing attacks - not much can be done about this one except user education (and I know how little that can tend to help): I specifically laid out the idea that if there were an unsuccessful try or two, the account would be flagged to create a new OTP on next login for the user (although this might be helpful for a man-in-the-middle attack?) - so if the user was educated that they would *NEVER* get more than one or two trys before they had to get another OTP, they would know a phishing attack being used to try to guess the OTP layout.

Even so, it seems like this idea of mine is a wasted effort - if it isn't secure, it isn't secure. I suppose there may be ways to make it secure, but all of the ways wouldn't increase the convenience of it (one way would be to have the issuing party of the OTP require physical access to get the OTP after it is generated, instead of sending it to the user to print out - would work OK for an office, if handled by IT, but not for home use), and phishing attacks would still be possible...

Re:Simple 2-factor authentication solution...

[csirac]

Don't take my word for it, I'm just a lowly EE with a passing interest in crypto... but as far as I can tell, your propositition isn't particularly any more vulnerable to a man-in-the-middle or phishing attack than other methods.

You probably know already what MITM is about, but let me waffle on some more :-) It behaves totally transparently to both the end-user and server, as if it wasn't even there, and making itself a part of the un-encrypted communications path - monitoring all your actions in plaintext. It begins by, perhaps, stealing the private SSL keys from the server so that as far as the end user is concerned, they're dealing with the same old server. They must also hack the end-user's network so that the user's DNS is poisoned to go to a different IP address for the MITM server, and/or re-routing the legit IP to the MITM server. Given the poor security history of various consumer DSL routers, this wouldn't be beyond the realms of possibility. This could all also be achieved hacking the desktop PC itself - wasn't it Valve (guys that ended up having to deal with leaked Halflife 2 source) that got hacked via a carefully crafted email that installed a back-door via an exploit of an Outlook bug? Anyway, the MITM connects to the real server pretending it's the end-user, and simply forwards everything the user does as if the MITM was the actual user.

As you can see, the MITM can monitor all your actions in plaintext. Neither the user nor the server knows the difference. As far as I know, nearly _ALL_ network systems are vulnerable to this, if any of the routers between the user and the server can be hacked. IP networks (as opposed to ATM point-to-point links) are especially vulnerable because we can't detect any additional latency the MITM causes because latency is variable and unpredictable on an IP network.

This is where quantum cryptography comes in handy, which involves the use of optical fibres between two points... in a nut-shell, it's vitually impossible to monitor passively because doing so changes the state of the (entangled) photons and hence corrupts the data stream. MITM is still theoretically possible, by again spoofing both sides to the other and acting as a decrypt/re-encrypt proxy to gain access to the unencrypted data stream, but the point is that this is detectable by an easily detectable jump in the comms latency. Unless the MITM has some crazy alien technology that far exceeds that which is installed at the endpoints, all such decryption/re-encryption will incur a very noticeable jump in latency because of the time taken to re-encode all the data.

Aside: just to give an idea of how obvious an MITM attack would be on fibre, we were able to measure the speed of light by sending infrared pulses down a 200m spool of fibre in 2nd year at university in a poorly funded lab. Current optical detectors/emitters which terminate these firbes have huge latencies compared to light itself - in other words, you'd need detectors/emitters and the re-encoding process itself to all happen "at the speed of light"... I'm not an expert in this field either, but AFAICT it's basically impossible today in 2005.

One type of "man-in-the-middle" scenario is known as "replay attack", which your scheme is vulnerable to.

A replay attack works by re-using old authentication data. In your case, the MITM could keep track of how many authentiction sessions you've done, and which passes have been expired on your OTP card. It could then start presenting the user with a challenge without actually forwarding to the real server; these artificial "failed" requests happen say half the time, and only present the "real" challenge to the user the other half of the time. Build up a collection of unused, valid responses which the attacker can hopefully have a good chance of gaining access to the real server at their own leisure without triggering too many failed attempts before hitting a challenge that has been learned.

Smartcard/USB hard-tokens which apply a crypto algorithm i

Re:Simple 2-factor authentication solution...

[jurik]

My main comments was that this was particular more secure than normal OTP passwords, so why bother to make a matrix with the information ?

And no there isn't anyway that you can make this secure (as the other poster have said in his reply there is always the man in the middle).

What you need to make this secure is some advanced cryptology (or said in other words - don't try this at home kids).

The are several approaches, one being Zero-Knowledge (ZK). ZK is a proof that you know a secret without telling the receiver anything about the secret. The proofs in these systems can't be recorded and played back, so in effect what an attacker can do is hear what is getting sent. If the proof succeds, then the server and client know they have the same key and they can derive a session key from this. Note that using this the man-in-the-middle will never learn the secret, he will just see the proof being sent over the line.

To give it a more pratical twist, consider the following protocol where you use a normal password and a one-time-password, just to improve security.
1. The user connects to the server.
2. The server replies, use OTP nr. 15, and use the nounce (random value) x_server.
3. The client makes a nounce himself: x_client
      Computes the response r = H(password, OTP(15), x_server, x_client), where H is a cryptographic hash function.
      The client then sends r, x_client to the server
4. The server checks that r == H(password, OTP(15), x_server, x_client).
      If this is true then it is considered a succesful log in.
5. Both server and client can compute a session key from password, OTP(15), x_server, x_client using a hash function. Note this should NOT be the same hash function as in step 3 or you have sent the session key in clear text over the network.

A couple of notes about the scheme above:
1. The one-time-passwords should be distributed securely and kept securely (as you already mentioned yourself).
2. It's not zero-knowledge, just something similar.
3. It's smart, so it's most likely patented.
4. Never think cryptology is easy, that when it gets really insecure.

Re:Simple 2-factor authentication solution...

[jurik]

Bob and Alice sharing the same secret is called shared secret.

A one-time-pad is when you use a shared secret to encrypt a message by taking the message and the shared secret and xor'ing them together.

Note that:
1. The key and message must have exactly the same length
2. The shared secret must be a uniform random (i.e. a shared sentence will not be enough)
3. The shared secret can only be used once

If that is satisfied it gives you the only provable 100% secure encryption (provided the shared secret is secret for all but Bob and Alice).

Please elaborate...

[cr0sh]

AC, can you (or anyone else?) please elaborate on why this is insecure? I am not a cryptologist, so I don't take offence at your observation, but I would like a more in-depth explanation...

Re:Please elaborate...

[csirac]

I'm not a cryptanalyst either, but from what I can see the main problem is that the "something you have" is too easy to duplicate. It can be copied, the attacker can mark off a couple of OTPs and use them for him/her self within a pretty significant period of time (say, over a weekend) and you wouldn't even know.

Then it's just a matter of planting a keylogger (software or hardware) or even just looking over the shoulder to get the "something you know".

I do agree it's a nifty solution that would be better than traditional user/pass, especially if the office is a trusted secure environment and you're wanting a publicly accessible authentication into a VPN or something, but not very convenient.

Re:Please elaborate...

[csirac]

Ah, I must have mis-read your post originally, I must have only skimmed it...

For some reason I thought you proposed an OTP system where each password was crossed off by the user (so the OTP selection works on sequence). In this way, the system would at least expose when your card has been copied and used (because now the user's set of passwords is out-of-sequence). Except for when the attacker is able to temporarily get your card and mark off a few passwords for you, the way I pointed out in my other post.

But this system doesn't even give you that protection... an attacker can photocopy your card and use it at his/her leisure at any time and you wouldn't know.

Still, it's nifty :-)

Re:Please elaborate...

[cr0sh]

There isn't really any way to get around the copying of the OTP - my thought on that was to train the user to keep the OTP safe (like you would your credit card and PIN number - although we both know that some people still have problems), and if it is ever suspected or known to have "gone missing" or copied, the user can easily cause the system to generate another OTP. Even so, other issues as pointed out by others cause this system to be fallible...

Re:Please elaborate...

[cr0sh]

The thing is, though, the system generated the grid, then to authenticate you later, it *randomly* picks a set of factors (actually, factor coordinates) for you to type in, sending you the coordinates of those factors (on the OTP grid you have), and you type them in (via an SSL secured page). It then matches the factors you typed in via knowing the coordinates it sent you, and sees if at the coordinates it sent you matches the data you typed in to what is in your profile. There isn't a way the attacker can get a copy of anything unless he copies the WHOLE thing (not impossible, sure, but ideally the user would be trained to know that he should keep secure access to the grid and not let anybody see it) - because the system is randomly choosing the grid coordinates to access. Unless the attacker gets really lucky and manages to copy the same numbers/coordinates that the system picks next, his guess won't likely match. I understand, though, that there are several other issues with this system that make it seem unworkable in a practical manner for most people - which is typical of most OTP systems.

RFP -

[tengu1sd]

Clearly your company lacks the skill set to submit an RFP outside of Ask Slashdot. You can temporarily hire an outside consultant to manage this process. Once the selection is made you'll need someone to manage the contract, then the product and vendor relationship and problem tracking . . . .

Dogbert Consulting Services
We secure your cash so you don't have to

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 .

IdentityGuard

[Epicyon]

tokenrevolt.com

Re:IdentityGuard

[Anonymous Coward]

hands down RSA is the best 2 factor solution

TeleAuth

[Anonymous Coward]

You should try TeleAuth. It has an easy to use API, PAM modules for unix-like OSs, and best of all, is free.

http://teleauth.com/

I use teleauth for 2x authentication

[Anonymous Coward]

This thread caught my attention, because I recently started using teleauth for my servers. It is an open spec, has open source client tools, PAM modules and integrates with OpenVPN.

You can also use it within your custom applications with its HTTP/S based API.

I have never used it on Windows, but the site says that this is possible through pGina.

Did I mention that it was free. (We pay for commercial support though).

Stupid q: don't you mean three factor?

[Webmoth]

I have to wonder if you don't mean three-factor authentication. After all, most systems already have two-factor authentication:

- Username
- Password

A system that simply lets walk-up users enter with no regard to who it is uses no authentication (think of a Windows system that boots to the desktop with no password prompt). A system where you have to identify yourself (username) but not verify the identity (password) uses one-factor authentication (think of a Windows system where there's a password prompt, so you have to type in a username, but that user has not been assigned a password). After all, you can say "If someone comes along and says his name is Sam, let him in the building. But don't let anybody named Joe in." Or, you can say "Let Joe in only if he says the secret code, and let Sam in only if his eyes are orange (but he doesn't need to know the secret code)."

To add biometrics, one-time-pad, SecureID, etc. to username and password would be to add a third-factor for authentication. You could say "Let Joe in only if he says the secret code AND his eyes are orange."

Re:Stupid q: don't you mean three factor?

[ITSecurityGuy]

Simple answer: No

Why: UserID and Password are both from the same factor: Something the user knows

http://en.wikipedia.org/wiki/Authentication

The methods by which a human can authenticate themselves are generally classified into three cases:

Something about the user e.g., fingerprint or retinal pattern, DNA sequence (there are assorted definitions of what is sufficient), voice pattern (again several definitions), signature recognition or other biometric identifier

Something the user has e.g., ID card, security token, software token or cell phone

Something the user knows e.g., a password, a pass phrase or a personal identification number (PIN)

Not All Tokens Are Equal

[Ararat]

Not all One-time Password tokens are created equal.

Not even all OTP tokens from, say, RSA Security -- the vendor I know best -- are created equal.

Specific mechanisms for "strong authentication" -- since the 1970s, by classical definition, an app which relies on at least two of the three factors (something known, something held, something one is) by which a computer can validate the identity of a pre-registered human user -- are designed for a particular threat environment.

Typically, in a variety of form-factors, OTP generators offer greater or lesser security on a spectrum -- greater or lesser resistance to various potential threats -- in a variety of pricing schemes. Among the competitive vendors, some support systems -- the authentication servers and agents -- are better adapted to a large volume of authentication calls, or a multi-server geographically-dispersed user base. In small tech-savvy environments, public domain OTP options will always have their place, although commercial enterprises typically want some solvent external entity to accept the risk and track the evolving threats.

RSA, as several posters have noted, has a unique "time-synch" OTP technology. A RSA SecurID continuously generates and displays a new 6-8 digit (or alphanumeric) pseudo-random "token code" every 60 seconds -- an OTP that is valid for no more than a minute or two. In RSA's security paradigm, a SecurID "token holder" is always required to supply a user-memorized password or PIN for two-factor authentication (2FA).

In the enterprise OTP token market it has dominated for nearly 20 years, RSA still closes about 7 of every ten sales. In the nascent consumer market for strong authentication -- where the scale and complexity of the implementations could be unprecedented -- all bets are off and a billion-dollar free-for-all looms.

Most of RSA's leading challengers -- Vasco, ActivCard, Secure Computing, CryptoCard, VeriSign -- have been mentioned, but no one has pointed out how many new vendors are rushing into this market, offering both new and old technologies. Some are big companies; others are tiny. Even low-tech options like TAM cards -- pre-printed lists of OTPs, now indexed, available on wallet-sized "scratch-cards" -- have become quite popular, particularly in Europe.

You'll find the classic OTP tokens for two-factor authentication (2FA) tokens with a variety of form-factors and cryptographic models: time-synch from RSA; mostly Challenge/Response and "event synch" -- click for an OTP -- from the others. One thing you won't find, despite some claims in this thread, are OTP tokens from anyone but RSA which offer RSA's "time-synch" short-term OTPs. None of the challengers, new or traditional, can yet mimic SecurID's patented functionality.

As you survey your options, it's important to keep your eye on the prize here. 2FA protocols are used to validate -- to a relatively high degree of certainty -- a claim that a "token-holder" is entitled to resources and account privileges on a (usually remote) computer or network, on which he has been pre-registered by an authorized party.

With more trustworthy authentication, your managers and security architects can enforce more rigorous accountability. (The gentleman who lamented his company's adoption of user-based strong authentication, on top of the client-based VPN authentication he thought was "more secure," doesn't get it.) Accountability is the goal.

Accountability is the ability to associate a consequence with a past action of an individual. To hold individuals accountable, it must be possible retrospectively to tie them with actions or events for which accountability is desired, or to be able to independently detect and respond to inappropriate behavior. Authentication can never be viewed in isolation. It is obviously dependent upon other critical elements in the security paradigm -- authorization and audit mechanisms, to be sure; but also network integrity and local PC and end-point host security as

try finding out a little more

[Anonymous Coward]

Dudes, as usual, I see a lot of strong opinions with little to no information, or wrong info. Try finding out a little more about each of the options. Two factor authentication is a really good idea and several companies do it well.

To answer of few of the issues some posters have with my employer (I don't speak for them but you can easily get in touch with someone who can) ...

- for the dude with the Cisco VPN setup: The certificate is from Cisco, not RSA. It is a good idea in that it validates the client machine, but it is configurable. Don't require them if you really think that will improve security. The issue with keeping a software token on the portable machine that needs access is one to think about. It is one option and has obvious risks, but someone thought they weren't as bad as you do. Is your laptop hard drive encrypted? Did you configure the soft token to use a password? Did you configure the soft token to only work on that one machine? There are certainly many other choices of tokens. Choose another if you don't like that one.

- For the dude thinking they can re-use a tokencode: good luck with that. If the tokencode changing every 30-90 seconds isn't enough for you, get a shorter one. If the servers synching every 100 seconds by default isn't enough, decrease the interval. If you don't like that, configure locking so it can never happen. If you don't like that, have your administrator pay attention.

- For all those who talked about one type of token: hey, all those providers have a huge variety. Off the top of my head, I believe my employer has: key fob, card, USB (with smartcard), software (Windows, CE, Palm, Blackberry), GSM phone, smart card.

- Trying not to turn this into a sales pitch, but sometimes you get what you pay for and sometimes the cheapest initial investment is not the best value. Look into some of the possibilities that RSA has.

Yeah, We've Got That

[mpapet]

We probably have what you are looking for. It's just released so there's an excellent reason why you couldn't find anything like it.

Features:
smart-card authentication for Active Directory clients.

It's really easy to convert as few or as many clients/users as needed.

Users can be enrolled and administered from any PC. (With proper authority and token)

If you have HID prox cards for physical security, we can manufacture a combination prox/smart card. If you have an ID card system, you may be able to re-issue an ID card with the smart card. Just depends on your software.

It's ready today. This is not a drill. Please contact me at your earliest convenience.

Michael 213-743-9181 ext. 231

Multifactor Authentication

[uberdru]

Have a look at TriCipher: They let you use cookies, generic USB drives, or smart cards as 2 factor mechanisms. . . .

Axent Defender and ANSI x9.9 authentication

[Nonesuch]

Please, please tell me PassGo is not using the same broken ANSI x9.9 authentication as the old Axent Defender products (e.g. SNK-004).

The Defender Hand-Held Token looks exactly like the old (physically unreliable) Axent Defender tokens, which used the (withdrawn in 1999) x9.9 Asynchronous authentication algorithm which was later proven to be extremely weak crytographically.

Many existing token products, including Vasco, Safeword, and ActivCard include support for x9.9 for backwards compatibility, as do a number of software applications.

Re:Axent Defender and ANSI x9.9 authentication

[petegc]

PassGo supports the Hand Held Token for customers already using the token and who wish to continue to use it. PassGo has working relationships with all the current major token vendors including Vasco, ActivCard and Aladdin and support for their latest devices has been added into Defender.

Entrust IdentityGuard

[Heather2]

I work with a company called Entrust and we have a competitive product to RSA's SecurID that suits the criteria you've outlined above that you may be interested in looking into. Entrust IdentityGuard is a comprehensive strong authentication platform for Internet and enterprise applications. This suite of strong authentication capabilities enables your organization to take a risk-based approach to tailoring your security deployment. The flexible deployment options enable you to match strong authentication methods to the level of risk associated with the different types of users, transactions, and applications of your unique environment. Feel free to contact me if you are interested in more information. You can also visit our website at http://www.entrust.com/identityguard/index.htm for more details.