What is a Time-Based One-Time Password (TOTP)?

December 4, 2022

TOTP stands for time-based one-time password (or passcode). A TOTP code is generated with an algorithm that uses a shared secret and the current time as inputs. This code is meant to grant users one-time access to an application.

TOTP can be implemented in both hardware and software tokens:

A TOTP hardware token is generally a physical fob or security key that displays the current code on a screen built into the device.
A TOTP software token is generally an authenticator application on a mobile device (like Authy or Google Authenticator) that displays the current code on the phone screen.

Unlike passwords – which are static and can be easily stolen – a TOTP code changes at set time intervals (usually 30 to 90 seconds) and is very difficult for attackers to compromise. This makes TOTP authentication a strong second factor in a multi-factor authentication (MFA) or two factor authentication (2FA) flow.

TOTP was published as RFC 6238 by the Internet Engineering Task Force (IETF) in 2011.

Fig: Screenshots of Google Authenticator with TOTP codes (Source: Vox)

How TOTP works

Before going into specifics, it’s important to understand how OTP generation algorithms work in general. Two inputs are used to generate OTP codes:

A seed. This is a static secret key that is shared between the token and the server. It is created when a new account is established on the authentication server.
A moving factor. This is a component that changes every time a new OTP is requested or at set periods of time.

In TOTP, the seed is a secret key that is shared between the authentication server and the token during first-time use. The moving factor used by the TOTP algorithm is Unix time. This algorithm uses a form of symmetric key cryptography since the same key is used by both the client and the server to independently generate the OTP.

Fig: TOTP uses time as the moving factor

Authentication using TOTP consists of two stages:

Registration, where the server generates the seed and communicates it to the client. Registration happens once, when the user chooses TOTP as their preferred 2FA factor for an app.
Validation, where the client generates a TOTP code using the seed and moving factor and passes it on to the server for validation. Validation happens every time a user tries to authenticate using TOTP.

TOTP registration

Here’s a simplified flow when TOTP authenticator apps are registered:

Step 1: The user enters their username and presents the first factor of authentication. They then choose authenticator apps as their preferred second factor while setting up 2FA.

Step 2: The server generates a shared secret key (the seed). The seed is embedded in a URL / QR code and passed on to the client. The server also stores the seed in a database (secret manager) for future retrieval.

Step 3: When the user clicks the URL or scans the QR code, TOTP registration is complete. The TOTP authenticator stores the seed in the client device in a secure manner.

Step 4: To complete the registration, a process of TOTP validation occurs (see the section below). Note: Some applications require two TOTP validations to complete registration.

TOTP validation

Here’s a simplified flow showing TOTP validation. This process happens every time TOTP is used to authenticate a user:

Step 1: The user begins the login process and successfully presents the first factor of authentication.

Step 2: The client generates a TOTP code using the seed and moving factor (Unix time). The seed used is the one created during the registration process. The client sends the TOTP code to the server.

Step 3: The server independently generates a TOTP code using the same seed and moving factor. The server then compares the two TOTP codes – the one it generated independently and the one it got from the client – to check if they match.

Step 4: If the two codes match, the user is successfully logged in.

Also read: Passwordless Authentication 101

TOTP vs HOTP

HOTP is the original standard that TOTP was based on. The “H” in HOTP stands for Hash-based Message Authentication Code (HMAC). Thus, HOTP stands for HMAC-based One-time Password. The main difference between HOTP and TOTP is how the moving factor is calculated.

In HOTP, the moving factor is a counter that’s incremented every time a new OTP is requested. This counter is stored on both the token and the server. The counter on the token increments by one when a new OTP is requested. The counter on the server increments by one when an OTP is successfully validated.

Fig: HOTP uses a counter as the moving factor

HOTP tends to be user friendly since it doesn’t increment until the user requests a new OTP. This means the user has ample time to enter the OTP. However, this also makes HOTP more susceptible to brute force attacks.

TOTP is generally more secure than HOTP and tough to crack with brute force attacks. However, the user has to input the passcode before it refreshes, which introduces the possibility of time-drift. To cope with this, the authenticating server must make it easy for users to input a new OTP if the previous one expires.

HOTP was documented and published by the Initiative for Open Authentication (OATH) as RFC 4226 back in 2005.

TOTP 2FA vs SMS 2FA

SMS authentication lets users log in to applications by entering a code sent to their phone via text message. It verifies users with a possession-based factor (their mobile phone). Although SMS authentication is still widely used, TOTP 2FA is considered the better option for a few reasons.

TOTP is safer than SMS since it’s a stronger proof of possession. SMS authentication is vulnerable to SIM swapping and man-in-the-middle (MITM) attacks where adversaries can intercept text messages and gain fraudulent account access. In 2016, NIST proposed that SMS be deprecated as an out-of-band second authentication factor.

TOTP is also usable in a wider range of scenarios than SMS 2FA. As covered earlier, TOTP doesn’t depend on Internet connectivity, mobile carriers, and delivery rates. TOTP is faster on average than SMS. Moreover, TOTP doesn’t require applications to collect user PII (Personally Identifiable Information, like phone numbers), making it viable for a larger pool of users including discerning ones that are reluctant to share their phone number.

Benefits of using TOTP

A recent report on MFA spending found TOTP authenticators (58%) to be one of the most popular MFA form factors other than passwords. Here are some advantages of using this authentication method:

Safer than just using passwords: TOTPs are meant for one-time use, which makes them resistant against replay attacks where the attacker intercepts and records data (like a static password) to use later. Using one-time codes as a second factor also reduces risk when user passwords get stolen.
Primed for wide adoption: Users like TOTP mobile authenticators because no codes need to be remembered and they don’t require new hardware. Mobile authenticators can be used for both enterprise and consumer contexts. Authenticator apps that support biometric authentication add a strong second factor and protect users even if their device gets stolen.
Can work offline: Since the TOTP algorithm uses a shared secret key and Unix time as inputs, the server and client can independently generate and validate one-time codes without needing an Internet connection. This makes TOTP usable in a wide variety of scenarios, including when users are traveling internationally, are on a plane, or are generally in an area with poor network connectivity.

Drawbacks of using TOTP

There is no authentication silver bullet, and that includes TOTP. Here are some risks to keep in mind while using TOTP:

Uses shared secrets: The seed used in TOTP generation are shared secrets, which is never an ideal security practice. Shared secrets make the server an attractive target for attackers. If they steal the secrets, they can generate passcodes to fraudulently access user accounts. It’s important for the shared secret to be stored securely on both the client and server side.
Depends on user device: If the user’s device is stolen, lost, or broken, the TOTP authenticator will no longer function as intended. In these cases, the application must find other ways of authenticating the user before reissuing a TOTP authenticator. That said, the likelihood of lost or stolen devices is much lower than the likelihood of stolen or leaked passwords.

TOTP authentication with Descope

Adding TOTP authentication to your app can be complex and time-consuming, taking away dev focus from other business-critical activities. Descope abstracts away the implementation details of TOTP authentication with a drag-and-drop workflow editor.