Accept

We use cookies in order to save your preferences so we can provide a feature-rich, personalized website experience. We also use functionality from third-party vendors who may add additional cookies of their own (e.g. Analytics, Maps, Chat, etc). Read more about cookies in our Privacy Policy and Terms of Service. If you do not accept our use of Cookies, please do not use the website.

Header Image

More Than You Ever Wanted to Know About Two-Factor Authentication

December 05 2017
December 05 2017
By

Two-factor Authentication (2FA) often seems like magic. However, it is, like most things in the world of security, based on mathematics. This blog post will dive into the specifications and algorithms used by 2FA and tell you more than you will likely ever need to know.

Origins

The definitive origins of “2FA” as such are not as clear as one might think. However, the original OTP (One-Time Password) scheme for authentication was developed at Bellcore, primarily by Leslie Lamport, the developer of the algorithm. Several other contributors were involved.

The Second Factor

For authentication to count as 2FA, it has to consist of two factors. One of these is generally a password, and for the purposes of this blog post, it is a password. So when talking about how 2FA, we are mostly interested in how the second factor is generated and validated technically.

Popular 2FA algorithms

The most popular algorithms for two-factor authentication are:

  • HMAC-Based One-Time Password (HOTP)

  • Time-Based One-Time Password (TOTP)

HOTP

Have you ever had to log in using a code-generating device — perhaps to a bank? That device was most likely using HOTP. HOTP is practical for such devices because they generally do not store the current time, a core requirement of TOTP.

Yubikey devices also use HOTP.

HOTP is specified in RFC 4226. The primary components in the scheme are:

  1. A shared secret, at least 128-bit

  2. An incrementing counter, synchronized between the server and the client

  3. A throttling parameter

  4. A resynchronization parameter

How it works

Devices using HOTP typically come pre-installed with a shared secret known by the server. For example, your bank may ask you for the serial number of the device when you try to log in after having gotten your code generator or received a new one. It can then retrieve the shared secret based on that and verify your 2FA codes.

To aid in security and prevent brute force attacks, the server should only allow a certain number of failed attempts before locking out the user. This is where component three, a throttling parameter, comes into play. You’ve likely encountered this on the Internet before. For example, if you have entered your online banking password wrong around three times, you may have had to wait a day or call technical support before you could try again.

The other interesting feature of HOTP is resynchronization, and this is where component four, the resynchronization parameter or window comes into play. The server will check a specific range of possible value matches, and reject the authentication if none of these work. It often checks something like the next 100 values from where the current counter is set. That means that it is theoretically possible to get into a situation where you’ve pressed the button on your token generator too many times and exceeded the window that the server checks. You’d then need to get a new token. In practice, though, this is exceedingly rare, which is why the method works well in the real world.

TOTP

HOTP was, in a sense, the original mass-market 2FA implementation, and it is still in wide use today. It’s good, and it adds more security to logins. However, its main disadvantage is that it requires the user to carry around an extra token-generating device.

Enter TOTP. TOTP is a based on HOTP, and it’s what you most likely associate with the term “2FA.” Rather than using a counter to synchronize with clients, it uses time. The specification also provides for using more secure algorithms (HMAC-SHA-256 and HMAC-SHA-512) vs. HOTP, which uses SHA-1.

TOTP is what one typically uses in code generator apps such as Google Authenticator, Authy, LastPass Authenticator, and others that do the same thing.

How it works

TOTP is specified in RFC 6238. It differs from HOTP in that:

  • Instead of a counter, the client and server use an initialization time and a time step parameter.

  • Resynchronization works a bit differently, since this algorithm is time-based.

  • Old 2FA codes quickly expire, whereas a stolen HOTP code could theoretically be used to log in to a compromised account.

The initialization time and time step parameters are essentially the same as the counter in TOTP, but time is always moving, so it is dynamic rather than static. Similar to HOTP, the client and server exchange a secret key during setup. The one-time codes are then generated using the number of time steps from the initialization time.

What’s a time step?

It is a bit easier to give a clear example here. Let’s say that client and server set their initialization time to July 31, 2017 at midnight. The length of a time step is set to 30 seconds, which the specification recommends.

A code is generated at 12:00:29 AM. Here, the time step is 0, since 30 seconds has not yet elapsed since the initialization time. But at 12:00:30 AM, it becomes 1. At 12:01:00 AM, the time step is 2, and so on. As long as the client and server generate codes against the same time step (all other things being equal), the codes will match, and authentication will succeed.

Resynchronization

Your next thought may be, “OK, Kevin. But for many devices, time is hard. Clocks get out of sync. Network latency might mess things up. What then, Kevin? What then?”

I have an answer for you: it’s more or less similar to what HOTP does. The server can look back/forward for a few time steps to check if the code would have matched in that case. It is important it’s not too lenient here, since that can reduce security. But it typically does this and records the time drift from the client. It can then be stricter on future logins or check the identity of the client in other ways if they don’t log in for a while and the time drift changes too much.

In Conclusion

We’ve looked at how 2FA works with the HOTP and TOTP methods, as well as how these are implemented. I encourage you to read the specifications, which we’ve linked to, if you would like to learn more.

I caution against implementing your own 2FA implementation from scratch. As mentioned in our overview of 2FA, it is better to rely on established libraries and extensions for this.

As the many compromises over the last few years have shown, security is hard.


Comments:

Leave a Comment

Name*
Email Help Tip
Website
Comment*
Characters Remaining: 5000