How TOTP works

TOTP (short for Time-Based One-Time-Password) is the most used MFA solution. It's when you need to enter 6 digits generated by your phone during a login. It greatly enhances security for your accounts and is a best practice to use it.

In this article, we'll dive deep how TOTP works and in which cases it constitutes as a second factor. As you could guess, there are some finer details here.

Book

A Practical Guide to AWS IAM

How to Write Policies, Control Access, and Secure an AWS Account

TOTP: comparing texts

TOTP is an algorithm to securely compare two texts for equality. It does so with:

• No communications between the parties except for the digits
• Does not reveal the secret values
• And the verification code is short-lived and can be used only once

Using TOTP starts with a setup process. This is the QR code that you need to scan with your phone:

Since a QR code is just a way to encode text, we can look into it:

otpauth://totp/Amazon%20Web%20Services:abc@278868411450
	?secret=CBXPGL3WXU3Y5GV3G5YMASNXEKTWRHWHEQ4UEMKUY3ABZZ4KVE5HE2Y7AUXSBZVU
	&issuer=Amazon%20Web%20Services

It looks like a URL and it has some parameters. It encodes some values that is purely for cosmetics reason: the user and the issuer that shows up in the list of added accounts. Then there might be parameters that define how to generate the tokens, such as how many digits to show, how frequently to change them, and what hash algorithm to use. There are defaults (6 digits, 30 seconds, SHA-1), so they are not shown here.

Then the most important part is the secret. This is the text that your mobile phone uses to generate the tokens and gets compared with the service's stored secrets.

You can easily generate QR code that can be used by authenticator apps. For example, FreeOTP's online tool is a simple way to do it:

How login works

After the setup process, there is a secret value stored on both ends: the authenticator app and the service you're logging into.

The app on your phone takes the secret, the current time, the parameters, and calculates an HMAC value (short for Hash-Based Message Authentication Code). This is a deterministic and one-way function so it does not leak the secret key. Then there is a truncation that converts the result into the digits.

The server does the same as it has all the necessary parts. If the two values match, that proves that the authenticator knows the secret and the login is approved.

When TOTP is MFA

MFA, short for Multi-Factor Authentication, is when you use multiple items from this list as part of the login process:

• what you know (password)
• what you have (hardware key)
• what you are (biometrics)

So, if TOTP is an algorithm that proves that you know a secret, how is it a second factor? After all, a password ticks the first item on the list already.

TOTP is a second factor when it is on a different device. Even then it's just an approximation of a real "what you have"-type factor as it can be cloned just by reading the secret text. In practice, it is "good enough" when used correctly. If you log in on your mobile phone and you generate the token from the same phone, it's not really a second factor. Similarly, if you store the secrets in the same password manager as the password itself, it's also not a good MFA. Granted, there are some benefits even then, but it's way weaker.

Dedicated hardware

To solve the second factor problem, you can buy hardware tokens that provide protections for the secret key.

(Image from Amazon)

These tokens come with various capabilities. Some has a camera, so you can scan the QR code. Some needs to be programmed via NFC, or some other way.

Because of the protections for the secret, if the setup process is secure then these count as true second factors.

Problems with TOTP

Backup

A huge pain point of most MFA solutions is that backup is an afterthought and TOTP is no different here. For example, Google Authenticator, probably the most well-known TOTP app does not provide any ways to replicate the secrets. This means, if you lose your phone then all the secrets are gone and you are locked out of all affected accounts.

Some people take screenshots of the QR codes, but that's not really a good solution as these images can leak.

Authy provides a cloud backup that is both usable and secure enough. Then Aegis can be configured for automatic and encrypted file-based backup that you can sync anywhere.

So, there are solutions for recovering the keys, but you need to be aware of the problem.

Time desync

As the algorithm requires the current time to be the same at the authenticator and the server, clock drift can cause problems. While usually there is a tolerance that accepts slightly off-timed tokens, in practice if a clock drifts then it will reach the point where the tokens are not accepted anymore.

With mobile apps it's less of a problem as they automatically sync the time. But I still experienced this several times. One way to check if incorrect timing is the problem is to go to time.is that tells you how accurate the clock is.

With dedicated offline tokens, time desync is more pronounced. Surprising as it is, it is very hard to make a clock that is accurate for years. The tokens I worked with provided a way to sync the time again, but that's up for the exact model.

Other use-cases

I recently read about an interesting usage of TOTP that is outside the topic of logins: make your laptop authenticate to you.

This uses the TPM (Trusted Platform Module) to store a secret value. Because of how TPM works, it can only be accessed when various parts of the system that is responsible for booting the OS is in a specific state. So, the laptop can read this value, show the digits, then you can use your phone (or other TOTP device) to verify the secret. If the digits match, you can be sure that nobody messed with your computer while you were away.

Conclusion

TOTP is a good way to add a second factor to a login process as long as:

• Generate the tokens in a different hardware than you log in
• There is a backup in place