One-Time Passwords - roadmap

Navigating the OTP Landscape

One-time passwords can be a tremendous benefit to security, but their use is misunderstood, and the technology is hard to put together especially if you're trying to do it all with free software. I'm writing this to help you (and really myself) find your way through the poorly documented and misunderstood OTP universe.

Bear with me, as I try to figure things out I'm going to categorize them in my own way, and for better or worse will probably end up inventing some of my own terminology - I'll try to make it clear when I'm doing that. For one thing, I'm going to use "OTP" to refer to both individual passwords, as well as the overall technology.

What is this

One-time passwords are passwords that are used once and then thrown away. A mechanism is provided one way or another to supply the user with an endless supply of these passwords in a secure way. This can be a small dedicated device you carry with you, or a program on your cellphone, laptop, or other system. It can also be a printed list that you renew periodically. Whatever the mechanism used, I'll refer to it from now on as a "device" (including paper printouts).

Initially, OTP was developed for people to use in non-secure environments, e.g. telnet logins when ssh wasn't available. Because of this people have it in their heads that OTP is only used in such cases. But in our modern world, hackers have become very adept at trapphing ssh passwords, via key-logging, and replaced or front-ended versions of ssh, su and other software that requires passwords. Today, even though you are using ssh or other secure lines of communication, OTP still makes a lot of sense, and can enhance your security considerably. Where I work, we've certainly had our ssh passwords compromised through a variety of methods.

In other words, OTP is still for non-secure environments, but our definition of "non-secure" has changed considerably.

Overview of Schemes

I'm going to group things into four major categories. The first three are all similar - a mathematical algorithm uses a seed value to calculate an infinite series of pseudo-random passwords. These three differ according to how passwords are selected from the infinite list.

The first OTP approach is "time-synchronized". Ever second, or minute, or whatever arbitrary period of time, counters on both the server, and on your device increment, and a new password is in use. Typically there is a window, where X older and Y newer passwords will also be accepted. This is done so the time synchronization doesn't have to be perfect, and also because it takes slow human beings a bit of time to read and enter the OTP.

The second approach is what I'm going to call "lockstep-synchronized". Each time you generate a new password on your device, it increments it's own internal counter, and each time you actually log in, the server increments it's counter. Typically, the next X passwords will be accepted, so things can be a little bit out of sync, and the server can automatically resyncrhonize.

The third approach is "challenge-response". In this case, it doesn't matter if the passwords are generated in order or not (they often still are, for other reasons). The server picks a password, and when you authenticate it offers you a "challenge", which is really just telling you to look up password #X. You enter X on your device, and it generates password #X.

The fourth approach is completely different. With this approach, your device is a communications device, usually a pager or cellphone. When you attempt to authenticate, the system sends your password to your device, and you use the password to log in. No seeds are required, the passwords can be completely random. This is generally referred to as "SMS-OTP".

Two factors overview

One possible benefit to OTPs is "two-factor authentication". This means that to authenticate, you need two different things: something you have, and something you know. There's also a third available factor, something you are, e.g. fingerprints, retina scan, voiceprint, face recognition, etc. Generally this is into the realm of really fancy expensive stuff, and beyond the scope of this article (although I bet you could make a really cheap and cool face-recognition setup with free software and cheap webcams).

What I've described so far is not two-factor authentication. An OTP is just a single factor, it's (more or less) something you have (like a cell phone, or a dedicated OTP calculator). To make this two-factor, a secret password that you know is also used somehow in the OTP authentication. One way simple way is that when you enter your OTP to login, you also enter your secret password right next to it. I'm going to call this a "PIN". Another method is that you would need your secret password to unlock the device you are using to generate OTPs, which I will refer to as a "passphrase". In other words the distinction between these names as I'm using them here is that a PIN is a plain password used together with an OTP, while a passphrase is a password used to obtain an OTP.

Of course PINs don't have to be numbers, and passphrases don't have to be phrases. But over time "passphrase" has become a common way to refer to passwords that unlock other security mechanisms. So yes it's kind of arbitrary terminology, and I'm making this distinction artificially. The literature out in the world sometimes matches what I'm doing here, but not always. If you have a better suggestion for terminology, please let me know.

Two-Factors - which is better?

PINs and passphrases both have advantages and disadvantages. And it is possible to use both (in some cases this is redundant, in others it may be beneficial).

If your device is a printed list of passwords, then a passphrase is fairly impossible (although one could print the list "wrong" such that you had to add a number to every password, or something like that).

PINs can be snooped as they are typed, and at first glance may seem to ignore the point of OTP. But if we profile typical hacker scenarios, it makes more sense: someone may find your device, and may be able to identify the account and attempt logins, but can't get in without the PIN. And someone may find your PIN with a keylogger. But they won't have your device. The opportunistic hacker would never put the two together. Only a stalker, targeting a specific individual, might be able to eventually compromsie both, but this is a very rare profile for a hacker, and not a significant concern for most sites.

Passphrases are generally safer than PINs, because they aren't sent back during authentication, so there is less opportunity to eavesdrop. This is not to say it's impossible. Phones can be hacked too, and people can just watch you enter it into a device. But it looks to me like the passphrase approach is generally better.

However I should point out that it's important to think about your device. Ideally devices are fully separate from the computers you use to authenticate. There are applications you can install on your laptop or desktop that let you calculate your one-time passwords directly on the computer. But using these means that a hacker could have one-stop shopping to find your passphrase, and the seed you use to generate your OTPs. The calculator is more ideally only on a separate device.

It should be observed that the something-you-have device can still be characterized as something-you-know. A piece of paper has information that could be copied. A phone has an app with a seed that can be read out and copied. A dedicated calculator has a seed built in, although in that case one hopes that the device is fairly tamper-proof. And of course, the seeds are also stored somewhere on an authentication server, and must be protected there as well.

Even with SMS-OTP, the phone is like something-you-know, because it is possible to snoop phone transmissions. So knowing the encryption method and secret for the text message could be a problem.

With SMS-OTP, it may make sense for the paranoid to use both a passphrase and a PIN. The OTP can only be snooped over the phone network. The PIN can only be snooped over the authentication platform (computer). And the passphrase can only be snooped on the OTP device (cell phone). A security person might still call that two-factor, but for the hackers it's three different things to grab.

What's the best device?

Different OTP devices have different benefits. One obvious concern is loss of the device. It's possible to make some arrangements for other means of authentication in the event of a lost device, for instance simply falling back on a traditional password. That's a policy decision that's outside the scope of this document. But when you lose a device the immediate concern is someone else finding it and using it. Whatever device you lose, one hopes that you have NOT written any identifying information on it. Nothing can be more fun for a hacker to find than a piece of paper with a list of passwords that has the account name right at the top. Or an OTP calculator that is similarly labelled.

Cell phones are a very popular choice now, because so many people already have them, and carry them all the time. There's nothing extra to carry. But phones have some significant disadvantages too. It's probably pretty easy to figure out who owns a cell phone, especially a smartphone. And even to figure out likely account names and hostnames (from any email addresses being used). It's also usually possible (and easy) to extract the seed from the cell phone. For these reasons, if a cell phone is used as the OTP generator, it's doubly important to use a PIN or passphrase.

Dedicated OTP calculators are usually designed to be tamper-proof, and printed papers would certainly not list the seed, and so in these regards both can be considered more sercure than a cell phone.

(In theory, a printed list of passwords could be used to uniquely identify the original seed. If the mathematical algorithm is secure, this should be statistically impractical, but I'm not sure of the current state of the algorithms, and if they've been evaluated for this sort of compromise.)

The primary downside to dedicated OTP calculators is that they cost money, and they are generally associated with servers that cost money too. It's also a bit more of a nuisance to carry them, although most nowadays are very small and can sit on a keychain. This size has a minor disadvantage too though, that most of these small devices have no key entry, and as such can not have a passphrase. A PIN can still be used though.

And, as I mentioned previously, installing a program on your computer that serves as the device is usually a poor choice, because if you're doing two-factor you're making both factors available to hackers in a single location.

Lockstep-Syncrhonized OTP

Generally some syncrhonization procedure is needed when you first set up your device. You enter two or more OTPs in sequence, and the a program determines from these how far along you are in the sequence of passwords, and records this information in the authentication server. The server then knows which passwords to expect. The obvious problem is getting out of sync.

If you accidentally generate several keys on your device without using them, your device will become too far ahead of your authentication server, and you will not be able to log in until you resyncrhonize. This might only be accomplished through a helpdesk and a human being. Or a program could be used that can only be run if you are already logged in (i.e. if you are physically present and logged in at a desktop system you could run this program). Or through a web page which uses other means to authenticate you.

Another issue related to syncronization is that you can't easily use more than one device. If you do, then you'd have to remember to use up the same password on all devices to keep them in sync. This sounds like a recipe for confusion and frustration. In theory, you could use paper as a device, crossing off password as you go, and then when you return to your physical device you could sync it to the paper by using up the crossed-out passwords.

This isn't totally a negative, as one could easily argue that it's a benefit to encourage people to use only a single device to generate OTPs, because users will be less tempted to install an OTP generator on their laptop or home system.

Another issue with lockstep synchonization is that with some devices (e.g cell phone apps), the sequence can be reset to the beginning, the server resyncrhonized, and passwords re-used. This is a bad idea, as a hacker who's been logging passwords might notice this, and be able to see which passwords are coming next. OTPs should never be re-used.

If implementing lockstep-syncrhronization on multiple authentication servers, it is critical that they have a way to share the synchronization information. Otherwise multiple logins on one server will cause another server to be too far out of sync.

Time-Synchronized OTP

Synchronization can also be a problem with this scheme. However in practice dedicated devices are highly reliable at staying syncrhonized. And cell phones generally get their time from the cell phone network, and are very accurate the vast majority of the time. When cell phones are wrong, they have the advantage that the time will correct itself.

Depending on how the cell phone stores time, and how the app is written, timezones can be a problem. If the times aren't synchronized to a universal time, traveling to a different timezone can cause your phone to reset it's clock in a way that will ruin the synchronization.

Lockstep has one slight advantage over time, and that is that everybody knows what time it is (despite the song by Chicago). If your seed was compromised, then time-synchronization is immediately compromised, whereas with lockstep syncrhonization, a hacker would still have guess where you are in your sequence (depending on how he compromised the seed - if he got it from the server he may have stolen state information too. This is only a slight advantage though. If the lockstep started at password #1, then the hacker doesn't have to try very many keys in order to authenticate. And once the seed is compromised we shouldn't really hold out hope anyway.

On the other hand, time-synchronization has a significant advanatage in implementation on the server end. If multiple authentication servers are to be used, the servers have to be syncrhonized with each other. For time-syncrhonization, this is probably not a problem, as the servers' clocks are probalby already syncrhonized.

One additional disadvantage is the possibility of reusing passwords. With all the other methods, a password should only be valid once. However (depending on implementation), a time-synchronized password might be re-used multiple times during the login window. This allows the possibility of someone snooping the password on the network and immediately logging in with it themselves.

Time-synchronization is perhaps less well-suited to a paper device than others, as you'd need a long list of times and passwords, and it would need to be updated daily. In certain security situations some might find this attractive though.

Challenge Response OTP

Challenge response has no synchronization problems. One might consider it slightly more cumbersome, as it gives you an extra step (entering the challenge into your device) when you authenticate. And it may be harder to retrofit to existing authentication technology, as your authentication interface needs to be able to offer a challenge.

If the challenges are in sequence, then this is well-suited to paper devices with lists of passwords. And I see no reason to randomize the challenges, since the challenge is completely public anyway. [Please leave a comment at the end if you see any benefit that I'm missing].

Challenge-response avoids problems of synchronization with the user - if the user's device is operating, they can always respond to any challenge. However, passwords should still not be re-used. If passwords are picked randomly, then a database must be kept of which passwords have already been used. This is a good argument for continuing to select passwords only in ascending order (possibly with gaps). If multiple authentication servers are used, then they still must be kept syncrhonized in some fashion to avoid password re-use.


This is the one that's different than all the rest. There is no seed that can be stolen. There is absolutely no way to predict the next password (depending on implementation). In order to login, you must be able to receive this text message. Of course, there is equipment and software out there for watching the text messages fly by. If this is implemented with unencrypted text messages, it's imperative that it be used together with a PIN.

Ideally this will be used with encrypted messages, together with an app on the phone that can decrypt them. And protecting the decryption key with another password gives you two-factor authentication.

If you lose your pager or phone, you can't log in until you get it replaced. There is no paper list alternative, unless SMS-OTP is implemented with a seed value instead of more random passwords. It probably doesn't make sense generally to use seeded OTP with SMS-OTP, however in the case that SMS-OTP is used as a backup in case some other OTP device has been lost, it might be an acceptable policy.

It may seem counter-intuitive at first to broadcast a password over a wireless phone network, but with proper implementation this may arguably be the most secure.

Other Vulnerabilities

One vulnerability with all of these except SMS-OTP is that if your authentication server is compromised, the seeds may be accessible. It's entirely possible to have these encrypted on the server, although I'll observe that if your auth server is compromised, you are already screwed, as the hacker would have many options by which to mount an attack.

One very significant problem in any kind of authentication is the man-in-the-middle attack, and OTP is as vulernable to this as anything else. With this attack, the hacker sets up a fake interface for authentication (e.g. a fake web page, or an email phishing attack). Whatever you enter is passed on to the real interface, allowing the hacker to authenticate, and leave you with a failure message. This attack has been successfully used for bank fraud in Europe, where SMS-OTP is a popular way of validating electronic transactions.

The solution to man-in-the-middle is really separate from OTP. Regardless of how you are authenticating, you need a method of insuring that you are communicating with the legitimate service. In the case of ssh, this is provided for by host keys. If they are not as expected, ssh issues a warning. (Unfortunately due to sloppy host key management, people are quite used to seeing this warning and ignoring it.) In the case of the bank fraud, the best practice is to provide transaction information in the message along with the validation password, so the user can see exactly what they are validating (e.g. "transferring $10,000 to Cayman Islands Account *****9489, validate with password '123456'). A concientious user will notice that this is not the transaction they originally requested.

The algorithm used to provide passwords is a possible point of attack. If a hacker collected one time passwords for a period of months and built up a large sample, then it might be possible to guess the algorithm and seed data used. An analysis of this is beyond the scope of this article, but this is theoretically possible for some algorithms. Challenge-repsonse could probably select keys from the sequence in an order designed to frustrate analysis. SMS-OTP could implement truly random password generation.

Available Software

Coming soon. Only non-commercial stuff will be added here, and it will probably focus on using OTP for ssh authentication.

Reader Comments (Experimental. Moderated, expect delays. Posts may be edited or ignored. I reserve the right to remove any or all comments, at any time.)

No comments

Add a comment

Tom Fine's Home Send Me Email