Understanding the generation of One-Time Passwords for use in Two-Factor Authentication

Introduction

Two-factor Authentication (2FA) is an extra layer of security that protects against unauthorised access by forcing users to prove their identity with two authentication factors. The first factor is usually something you know (for example, a password), and the second is something you have (for example, a security token). The most common implementation of the second authentication factor is a One-time Password (OTP) via an Authentication Application such as PingId or Google Authenticator.

But how do these applications work under the hood for implementing OTP? How do the server and client synchronise on the value of the second factor? It’s easier than you probably think — let’s find out.

Timed One-time Passwords (TOTP)

The main aim of OTP is to generate a temporary code (token) that can only be used once. For this to work, the client and the server must agree on the value of the temporary code. Enter TOTP.

Timed One-Time Passwords are a specific type of OTP generated using a time-based algorithm. The simplified explanation of how this algorithm works (documented in RFC6238 for the extra curious) is that it combines a secret and the current timestamp and uses a cryptographic hashing function (HMAC) to generate a random number. This number is then modulated to create the most common form of code, which is a 6-digit number, or more simply:

code = HMAC(Secret, Counter) mod 1000000

The counter is a value derived from the timestamp. It is usually a modulation of the timestamp to ensure that we can accommodate the fact that a code generated on the client will take some time to arrive at the server and that the server will validate the code subsequently. For example, if we want to generate a valid token for 30 seconds, we can calculate the counter as Counter = Timestamp mod 30. This will ensure that timestamps on or between the 0th and 29th second of a minute compute the same counter value and will, therefore, generate the same code.

So, for a server to agree on the validity of a code provided by the client, they both need to be able to solve the algorithm. Assuming both know the algorithm and have independent access to the (accurate) current time, the only other piece of information they need is the secret. The server only needs to share the secret with the client once, and then both can generate codes independently based on their knowledge of the current time.

Enrolling to 2FA

To simplify the next points, we will use a bank’s example of adding 2FA for customers who need to transfer money from their account on the bank’s website.

• User: This is the customer using the bank’s Website
• Authenticator App: This is an Authenticator Application installed on the User’s smartphone
• Website: The bank-owned portal that Users can use to transfer money
• Server: The backend server that hosts the bank’s APIs that are used by the Website

If the User is logged in to the bank’s Website and transfers money from their account for the first time, they must first enrol into 2FA. Enrolment is a one-off process. The Server will send a special URI to the Website, which is most commonly encoded and displayed to the User as a QR code. The URI will be specific to the User (the server must generate and store a different secret for each User of the bank’s Website). An example URI (and its QR code encoding) sent to the Website from the Server is:

otpauth://totp/Versent:me%40email.com.au?secret=KRXXI4CFPBQW24DMMVJWKY3SMV2EWZLZ&issuer=Versent&algorithm=SHA1&digits=6&period=30

For our discussion, the most important parameter from this URI is the secret. The authenticator App needs this value to generate codes specific to that User.

The User scans the QR Code displayed on the Website into their Authenticator App, which saves the secret to allow it to generate codes. The User will be asked to enter the code from their Authenticator App into the Website once or twice so that the Server can ensure everything is correct before completing the enrolment process.

The 2FA Dance

Now that the User is enrolled with 2FA, it’s time to transfer money! But first, the bank’s website challenges the User for their OTP.

The User can use their Authenticator App, which knows the algorithm, the secret it has stored, and the current time. Using this information can generate a code that the User can submit for the challenge. The server will then calculate its code based on the same information and compare it to what the User has provided. If the codes match, the transaction will be allowed.

Closing Comments

Cryptographic Hash

The use of a cryptographic hash — such as HMAC — is suitable due to the properties of cryptographic hashes:

1. Deterministic — The same input always produces the same output — This ensures that the client and server both arrive at the same code when using the same inputs.
2. Fast Computation — Quick to compute the hash for a given input — The codes only have a finite timespan, so they must be quickly computed.
3. Collision Resistance — Two different inputs should produce a different output — Low collision resistance would increase the likelihood of brute force attacks.
4. Avalanche Effect — A small change in the input produces a significantly different output — Since TOTP uses the current (modulated) timestamp the value of the Counter will only change slightly between successive codes. Without the Avalanche Effect, an adversary could predict how the hash will change and calculate future hashes.

Secret Handling

A unique secret should be generated per User and then stored in a suitable location (preferably in a different location from the User’s first authentication factor, e.g., password). If the secret is leaked, 2FA will be defeated.