I am teaching our Defending Web Applications [1] class this week, and yesterday, one of the students pointed me to a news release about Google implementing two factor authentication for its applications [2].

First of all, the mandatory primer on two factor authentication: Two factors means two authentication method groups. There are typically 3 different groups: Something you know (password), something you have (token), something you are (biometric). If you have for example a laptop login setup via finger print, you are still using single factor unless you also have to enter a password. And of course, two different passwords are not two factor. There is also the problem of users collapsing the tokens, by for example writing the password on the back of the smartcard. Now something you know becomes something you have.

Typically, implementing two factor authentication means buying tokens or smart cards for all of your users. This can be expensive (from what I have seen $50/user is typical in smaller deployments) and it is only manageable for users with whom you have an existing relationship (employees, in some cases customers). 

So how do you implement two factor authentication for "cheap"? Here are a few methods I have seen used:

Smart phone application as token, or other soft tokens

This is the route Google picked. The first time I have seen a system like that was OTP (one time password) tokens on old Palm PDAs. Of course, if you can turn the token into software, you could have a desktop application as well. Google appears to off the smart phone version only. The advantage of course is cost and ease of deployment. Once the application is written, it is pretty easy to deploy and there is no incremental "per user" cost making it ideal for a large deployment like Google. The disadvantage is the fact that it is software. It could be compromised by malware. It is very much possible for malware to "pull tokens" from the software to send them to an attacker. And attacker may even be able to clone the token without the user knowing. Verisign offers a free OpenID based system using phone based one time password tokens [4]. 

SMS Messages

It is pretty much free to send SMS messages via e-mail, in particular in moderate volume. SMS can be used to send a one time password to a phone. The advantage is again that you are using a phone the user already has and that the message travels out of band, at least the last step to the user. The cell phone becomes "something you have". The main disadvantage I have seen is that SMS is not totally reliable. Messages may be delayed or if you don't have reception you don't get the message. One could potentially implement a similar system using voice calls using for example an Asterisk server. This is still pretty cheap but probably not as easy to implement (Phonefactor offers a commercial solution like this [3]). Another problem may be the cost the user has to pay for incoming SMS messages. These days of course one could use a Google voice account to receive the SMS messages, removing the out of band advantage.

Paper based tokens

Print a sheet of paper with one time passwords. This works pretty well. I once had a bank in Germany back in the 80s that used just a system like this, and I believe still does. Very cheap to implement even on a larger scale, and hard to attack by malware. However, easy to attack with a copy machine and you wouldn't even know that you lost it.

Any other methods I missed?

 [1] http://www.sans.org/security-training/defending-web-applications-security-essentials-1442-mid
 [2] http://threatpost.com/en_us/blogs/google-adds-two-factor-authentication-apps-accounts-092010
 [3] http://www.phonefactor.com
 [4] https://pip.verisignlabs.com

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter