Time Drift in TOTP Hardware Tokens Explained and Solved

Multi-factor authentication by a Time based One Time Password (TOTP) generated with a physical device is, without any doubt, the staunchest approach to safeguarding sensitive data and securing access to your invaluable accounts. But being physical objects and having no internet connection gives physical TOTP tokens both their main strength and their major drawback. Without any connection to the net, the tokens’ internal clocks inevitably start drifting, and in a few years, this clock drift may become a major issue.

In this post, we will look into the time drift problem with TOTP hardware tokens in detail, see exactly why and how this issue occurs, describe how TOTP works and show you how we finally solved the time synchronization problem in the latest Protectimus Slim NFC tokens generation.

How does the TOTP algorithm work?

As has been mentioned above — TOTP is an abbreviation of Time-based One-Time Password. It’s a standardized cryptographic algorithm for generating unique one-time passwords, that remain valid only for 30 seconds. TOTP algorithm is a branch of HOTP – HMAC-based one-time password algorithm, so to understands TOTP it makes sense to understand the HOTP algorithm first.

What is the difference between TOTP and HOTP?

TOTP one-time passwords are valid only for 30 seconds. HOTP one-time passwords, in their turn, remain valid until the server receives a new one-time password verification request. TOTP algorithm is a much more secure version of the HOTP algorithm.

HOTP

HOTP is the parent OATH one-time password generation algorithm that generates a one-time verification code by mixing a secret key (a shared value) with a counter (a moving factor – variable).

  • A counter is the event of generation of the OTP password. Every time a new one-time password is created, the number of events increases by one, and this monotonously increasing value is used as the variable in the HOTP algorithm.
  • A secret key is the line of symbols shared by the authenticating server and the device on the user’s end (2FA token).
TOTP token secret key example

The HOTP algorithm processes and hashes the input data (secret key and the current counter value), them cuts the resulting hash to 6 or 8 characters, and this is when we get the one-time password shown on the OATH token.

TOTP

TOTP algorithm works exactly like HOTP, but, in its turn, gets its moving factor from the running time interval. In other words, TOTP algorithm generates one-time passcodes by mixing a secret key (a shared value) with a current time interval (a moving factor – variable). Therefore, it is very important for the current time on the server and on the token to match.

| Read also: One-Time Passwords: Generation Algorithms and Overview of the Main Types of Tokens

How do TOTP tokens work?

All of the existing multi-factor authentication tokens may be roughly split into two types — the software ones, which refer to using the user’s phone for generating or accepting one-time passwords (authentication apps, chatbots, etc.) and hardware ones (re-programmable or classic hardware OTP tokens). The TOTP algorithm itself can be used in any of these types of MFA tokens, but there’s a slight difference in their setup. Let’s dig deeper into this rather complex process.

The TOTP token enrollment

First of all, the user or administrator should connect the token with the authentication server. As mentioned above, the server and the token must “share” the secret key. There are two ways to exchange this secret key:

  1. The secret key can be generated on the server side and then added to the token.
  2. The token can be produced with the pre-installed secret key, then this secret key should be added to the server.

Situation 1: the secret key is generated on the server side

This procedure goes for software multi-factor authentication tokens and for programmable hardware tokens Protectimus Slim NFC.

When a user sets up TOTP token, the back-end two-factor authentication server generates a line of random symbols (numbers and letters), this string of symbols is what we call a secret key.

This secret key has to be shared between the user’s TOTP device and the authenticator server. Since the server already has the key it has to be saved on the user’s device by scanning the provided QR code or entering the symbols manually.

This is the procedure you will use, for example, to set up two-factor auth in Dropbox, Facebook, Office 365, etc.

How to set up TOTP token secret key in QR code

Situation 2 – TOTP tokens are provided with pre-programmed secret keys

The classic TOTP tokens have the secret keys embedded by the manufacturer, and these keys cannot be changed. This is the case when the secret key has to be added to the authenticating server when a user gets their TOTP hardware token from a vendor. So the end-user, or their system admin, have to be granted access to the validating server, which is not always the case.

This is the procedure you will use, for example, to set up two-factor authentication with classic hardware tokens in Azure MFA.

Pre installed secret key in hardware TOTP token example

Generation and validation of TOTP passwords

When the user logs into account protected with 2-factor authentication app they need to prove they’ve got the right OTP token with the corresponding secret key. This is when the user’s authenticator device mixes the secret key and the current time and provides a one-time password.

An identical process takes place on the server side. “Knowing” the necessary secret key and the current time, the authentication server generates the same OTP password. If the user’s and the server’s one-time passwords match, the user gets access to their account.

If either the time or the secret key on the token does not correspond with the ones the authentication server has, the access won’t be allowed. For the successful authentication, the time on the server and on the token must match.

Why time drift in TOTP tokens occurs?

Hardware OATH TOTP tokens do not have any type of link-up, neither to the internet nor to any other network. This makes them invaluable token-based authentication method. They are unbreakable. There’s simply no way to snatch the unique one-time codes these tokens generate, there’s no way to insert malware code or virus in the hardware token.

But the TOTP algorithm requires the security tokens to have a way to know the current time. So the manufacturers embed oscillators in these devices to give them an internal clock. With no connection to the internet, these internal clocks have no way to synchronize the current time, inevitably, over time they start to float.

Typically, the time discrepancy for a TOTP generator is about 2 minutes per year. Keep in mind that modern tokens have very good batteries that can last for at least 5 years. In a couple of years, the time drift becomes too big and goes out of the clock synchronization window. Meanwhile, the time server is always synced and precise. As a result, the authentication server and the auth token start to generate different codes and the user is not able to log in. And we get a useless hard token with a battery as good as new.

With the software-based multi-factor authentication app this is not an issue, since the phones, which are usually used for this type of authentication, sync the time via the internet. With the hardware tokens, this is the major drawback that’s been frustrating both the users and developers for years.

| Read also: The Pros and Cons of Different Two-Factor Authentication Types and Methods

How to deal with time drift in TOTP tokens?

Regulate time drift on the server side

The authenticating servers do have a recommendation by TOTP RFC 6238 standard to accommodate the time slack in both ahead and behind time steps and thus allow for less impact on the end-users.

The time sync software is to be set to check a specific number of time intervals within a specific time window before the OTPs are rejected and access is denied.

The suggestion is 3 tries with each time step of 30 seconds (usually one check on the current time and two checks on the two time steps back). So the maximum allowed time drift is usually 89 seconds (29 for the correct timestamp and 60 for the two steps backwards). The time sync server then can automatically record the time drift it detected and adjust the timestamp for the future use of the security token.

There’s a number of issues with this solution. While some two-factor authentication solutions do accommodate this protocol and adopt the recommendations, there are still a lot of those which neglect them altogether. Another issue is with the lifespan of the battery. As we’ve already established above — any modern OTP token has a longer lifespan and the time drift that occurs with these hardware tokens can become as long as 10 minutes, no server is ready to handle that. Finally, the longer a token is unused, the longer its time drift becomes, meanwhile the battery is as new as the day it was manufactured.

RFC 6238 TOTP algorithm resynchronization recommendations

Use TOTP hardware tokens with the time synchronization feature

Re-programmable TOTP tokens were created to become a safer substitute for the software-based type of MFA for those cases when admittance to the verifying server is prohibited (where hardware tokens are not supported, but MFA is still available via a TOTP app).

As of 1 May 2019, Protectimus Slim NFC programmable hardware tokens have one more feature similar to the software authentication tokens — they can sync time. You can say these tokens combine the best features of the two types of multi-factor authentication tokens and now they truly are invincible.

Since granting time adjustment as a separate function is a bit of a security risk, though a very small one, we’ve combined automatic time adjustment with the token’s programming process. Every time a new secret key is programmed into a Protectimus Slim NFC security token via our seed-burner application (for now available only for Android devices with NFC), the device invokes time sync. And since the re-programmable capacity of these tokens is unlimited, the time can be synced as many times as needed.

| Read also: 4 Reasons Two-Factor Authentication Isn’t a Panacea

Final thoughts

There are not many two-factor authentication issues, but the time drift problem has been a point of frustration for quite long. Well, we are proud to say it is not an issue anymore! Protectimus Slim NFC re-programmable hardware tokens with time correction for codes feature are ready to generate your unique one-time passwords for as long their very durable battery will allow.

Read more:

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

You have Successfully Subscribed!

Author: Anna

If you have any questions about two-factor authentication and Protectimus products, ask Anna, and you will get an expert answer. She knows everything about one-time passwords, OTP tokens, 2FA applications, OATH algorithms, how two-factor authentication works, and what it protects against. Anna will explain the difference between TOTP, HOTP, and OCRA, help you choose a token for Azure MFA, and tell you how to set up two-factor authentication for Windows or Active Directory. Over the years with Protectimus, Anna has become an expert in cybersecurity and knows all about the Protectimus 2FA solution, so she will advise on any issue. Please, ask your questions in the comments.

Share This Post On

Submit a Comment

Your email address will not be published. Required fields are marked *

Subscribe To Our Newsletter

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from Protectimus blog.

You have successfully subscribed!

Share This