Implementing two Factor Authentication on the Cheap

Published: 2010-09-21
Last Updated: 2010-09-21 14:00:31 UTC
by Johannes Ullrich (Version: 1)
15 comment(s)

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?


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

15 comment(s)


PhoneFactor offers a free service for up to 25 users, I have been using it with about 10 users or so on Server 2008 in conjunction with RDP for the past year and its been great.

Actually, Google is offering a solution of multiple options
After entering your password, a verification code is sent to your mobile phone via SMS, voice calls, or generated on an application you can install on your Android, BlackBerry or iPhone device.

Also, they seemingly offer to discard the requirement, based on user confidence in a given host's security, say one's secured computer.
Yubico ( has an interesting OTP solution too. Very cheap (25$ or less by key). Just ordered some and will be implementing those very soon.
PassWindow ( is a low cost OTP solution using simple plastic cards and a printed visual key pattern. It also has a security advantage by being able to perform transaction authentication (injecting transaction information into the challenges along with the OTP) so trojans on the mobile or any terminal cant MITM/MITB their way past the OTP like they currently do ie Zeus etc. Its also less vulnerable to phishing and phone based social engineering.
I would like to add to this cool post that two factor auth using SMS or a Smart phone applications can be done also using remote access SSL VPNs by triggering a smart phone using SMS. This is very inexpensive as well and a good alternative to RSA or other more traditional approaches.

Inexpensive Two Factor Authentication for
Creative Cloud Security Authentication technique using SSL VPNs and SMS two factor authetication

Application of this article:
1) If you want a cool security idea

2) Inexpensive way to add two factor to cloud access authentication
3) add two factor authentication and use your own AD active directory to be authoritative for access control.
We've released an open source version of the WiKID Strong Authentication Server: It offers a robust solution with a commercial/supported option.

Of note: we support a mutual https authentication system where the token client validates the targeted site's ssl certificate for the user. If the cert isn't what is expected, the user will not get the OTP. This thwarts MiTM attacks, which is frequently mentioned as a way around two-factor authentication.

I'm glad you've written this article. Too many people labor under the pretense that two-factor authentication must be expensive.

How about sending the password through a password protected voice mail.. It works for us... is a pretty slick paper based 2 factor system... the code is open and I think there are a number of implementations for useful scenario's like SSH.
Most sources I've encountered lately include a fourth factor class, "something you do" (behavior recognition). Examples of authentication "tokens" in this class would be speech patterns and how you sign your name (how much pressure you apply, how long you take, any pauses, etc.).

AFAIK, there are no inexpensive solutions that implement this class, so perhaps it's not so relevant to this particular discussion, but I mention it for the sake of completeness.
The US Treasury uses plastic cards with a grid system as an inexpensive two-factor system. After entering user-id and password you pick your card's serial number from the short listing, next they ask you to enter three values from the grid. A bit like battleship..."A5", "C1", etc.

Diary Archives