exploring software and hardware security

One-Time Passwords

Posted by davitb on October 2nd, 2009

I decided to continue the series of “user authentication” related articles (which I started with article Conventional Website Authentication Model and its Weaknesses) and bring more details about one-time passwords.

In this article I will overview the following topics:

Basic ideas behind OTP
OTP Types
Vulnerabilities
Standards and Applications

To make the illustration of OTP more practical we will implement a web server with authentication from scratch by trying to integrate an OTP scheme.

Basic ideas behind OTP

Consider a web server which has a database of users and implements a basic user authentication scheme based on passwords. There are various ways to implement a password based authentication server and key decisions to make while designing it. For example, the following questions need to be addressed:

Are we going to keep the copies of passwords on server side?
Are we going to have a certificate for server website?
What is the authentication protocol we will implement?
Are we going to send the hash of password during authentication?
…

These questions are interconnected. Answer to one will definitely affect the rest of them.

Let’s consider the simplest scheme:

The server keeps the hashes of passwords in the database (instead of real copies) and thus doesn’t take unnecessary security responsibility
Once the server received the password, it calculates the hash of it and verifies with the hash stored in the database
If the hashes are equal – user is authenticated

Everything looks fine with one exception. Replay attack. An adversary, recording a single authentication session would be able to repeat the steps and get authenticated with the server.

In order to prevent such attack servers usually implement PKI approach. They acquire a certificate from Certification Authorities (such as Verisign) and install it on server. When the user enters this website the browser automatically verifies the certificate of the web server via HTTPS (it’s based on SSL) and creates a one way secure connection. So after this is done the password will be transferred in SSL and will be encrypted with SSL session key. So no replay attack is possible.

This is the simplest and most famous approach for user authentication with web servers. However this approach has several problems which are discussed in my previous article – phishing/pharming attacks, password related problems and man in the browsers attacks…

Imagine that the password never transferred to the server. Imagine a scheme where web server could authenticate the user without receiving any confidential information… Let’s talk little bit about challenge response protocol.

Challenge-Response

Both user and server share a shared secret (password)
During authentication the server sends a random challenge to the user machine
User’s machine calculates a response with the following formula – CR=HMAC(RC, SS) and sends it back
After receiving CR, the sever calculates the same thing on server side and compares with CR
If they are equal – the user is authenticated

If the server is able to generate secure random challenges each time then there is no way to conduct replay, phishing and pharming attacks – because the user never sends a clear password to the server. Instead it sends a one time usable token – based on random number, shared secret and a cryptographically secure hash function. This becomes interesting, right? And note, in ideal case, there is no need to implement PKI based authentication for this scheme (though it would be good to have as other sensitive information is also transferring over wire, such username).

However this scheme doesn’t give much advantage if we are still using passwords. Man in the browser, and social engineering attacks are still possible.

Now suppose that the secret, shared between the user and server, is not a text based password but is a cryptographic key with the length of, say, 128 bit. And suppose that the user possesses a hardware token which is provisioned with this secret and this hardware token is used for authentication purpose.
The hardware has a basic functionality – when it received a random challenge (RC) – it calculates HMAC(RC, SS) and gives back.

So whenever user needs to authenticate with a web server, he puts this device into laptop and authentication succeeds automatically. No replay, phishing, pharming, man in the browser and password related attacks are possible now. Everyone is happy.

This is the basic idea behind OTPs. We have discussed only one type of OTP – challenge response, but as you will see there other types too. However all types share the following concepts:

User and server share a secret.
During authentication the OTP device generates a value which is used only one time by the authenticator and which can be calculated on the server too.
Server calculates it and compares with the one that user provided. If they are equal – authentication succeeds.

OTP Types

As far as I’m aware of there are five types of one-time password schemes:

Challenge response (the one that we discussed earlier)
- Note that this can be considered a real OTP only in case if there is a cryptographically secure random number generator installed on server.

Counter based
Time based
Counter + challenge response
Paper written OTPs

In case of counter based OTPs, beside the secret, OTP device and the server share also a counter. There is usually a trigger on the OTP device. When the user pushes this trigger, device generates a value, something similar to HMAC(counter, shared secret) and sends it to the server. Device increments the counter after the trigger is pushed and data is sent.

As server also shares all data contained in the HMAC it can calculate the same HMAC value and compare with the one that user sent. After authentication succeeds, the server increments the server side counter.

The concept of time based OTP is very similar to counter based one. The difference is that instead of sharing a counter the server and OTP device are calculating the OTP value based on time. In this case the OTP device must have a trusted clock and usually a time circuit is integrated in the hardware which is synchronized with the server time. So when the user pushes the trigger, the following value is calculated – HMAC(current time, shared secret). The server also calculates a vaue with the same formula and compares with the client’s one.

Counter and time based OTPs schemes share a common problem – the synchronization problem. When device’s counter or time gets out of synch with the server’s one there must be a way to synchronize them. These synchronization techniques usually cause lot of troubles to users and IT administrators and thus affect the overall price of installation.

There are also OTP schemes where a counter is combined with a challenge-response protocol. In this case prior to authentication, the server sends a random challenge (nonce) to the client and OTP device generates the OTP value based on the following formula – HMAC(nonce, counter, shared secret). The counter in this scheme makes sure that the OTP value will never repeat and the server nonce provides more security to the scheme.

There are financial institutions (mostly in Europe) which are using paper written OTPs. The concept is that the user receives a number of different OTP tokens (e.g. 100) and uses them one per one during authentication with a website. The server shares the same amount of OTPs and is able to compare them. These OTP tokens can be sent to the user via SMS or email.

Vulnerabilities

Though OTP is able to protect against phishing, pharming, replay, password related attacks however it’s still prone to the man in the middle type of attacks.

The following diagram illustrates the man in the middle attack on a challenge response OTP authentication.

Man in the Middle

A malware is installed in the browser
The user enters to a web site
Web sites sends a nonce (rand challenge) and requests for a valid response
OTP device generates the valid response and sends to the server
Malware records this response, generates a fake error message to the user (smth like “some error occurred, please try again”) and continues the session with web server by sending the valid response and getting authenticated.

These types of attacks cannot continuously succeed, especially in case of careful users. Usually users will contact with service providers and report about errors. Although the web site will cancel the OTP device after that but the attack already has been successful conducted.