How Authenticator App Codes Work: TOTP Explained
The six-digit codes in an authenticator app come from a shared secret and the current time. Here is how TOTP works, why codes change every 30 seconds, and its limits.
In this article
The six-digit code in an authenticator app is calculated, not sent. Your phone and the website each hold the same secret key and each compute the code from that key and the current time. If their results match, you have shown that you hold the secret. The method is called TOTP, short for time-based one-time password, and it is standardised in RFC 6238.
Where the idea comes from
According to Wikipedia, TOTP was published as IETF RFC 6238 in May 2011 and extends an earlier method called HOTP. HOTP, defined in RFC 4226, makes a code from the secret key and a counter that goes up by one each time a code is used. TOTP replaces the counter with a number derived from the clock, so no counter needs to be kept in step. The RFC states it as TOTP = HOTP(K, T), where K is the shared secret and T is the time value.
Step by step
- Set-up. The website creates a random secret and shows it to you, usually as a QR code. Scanning it gives the app the secret. According to Wikipedia, the code holds an otpauth://totp/ address with a label and a Base32 secret, plus optional settings such as digits (default 6), hash (default SHA-1) and period (default 30 seconds).
- Counting time. Both sides take the current Unix time, subtract a start time T0 (0 by default), and divide by the time step X (30 seconds by default), rounding down. The result, T, changes once every 30 seconds.
- Hashing. T is written as an 8-byte number and run through HMAC, a keyed hash, using the secret. The RFC names HMAC-SHA-1 as the base, with SHA-256 or SHA-512 allowed.
- Shortening. The long result is trimmed to a few digits. The RFC describes dynamic truncation: the low 4 bits of the last byte pick an offset, four bytes from that point form a 31-bit number, and the number is reduced to the chosen count of digits. Leading zeros are kept.
- Checking. You type the digits. The site runs the same calculation and compares.
Why 30 seconds
The RFC discusses the trade-off. A longer step means a code stays valid longer, which gives an attacker more time. A shorter step makes people wait and risks codes expiring while typed. The document recommends 30 seconds as a balance between security and usability.
Clocks that disagree
A phone clock and a server clock are rarely identical, and network delay adds more. The RFC says a verifier may accept codes from adjacent time steps, and it gives an example: accepting two steps back with a 30-second step allows roughly 89 seconds of drift. It recommends allowing at most one step for network delay. After a successful check, a server may record the drift and apply it next time, and for large drift it may require explicit resynchronisation with extra authentication.
The RFC also says a verifier must not accept the same code twice once it has been used successfully.
Limits
TOTP raises the bar over a password alone, but it is not perfect. Wikipedia lists two main weaknesses.
- Phishing. You type the code into a web page, so a fake page can capture it. The short validity limits the attack, because the attacker must pass it on quickly, but real-time relay is possible.
- Shared secret. The website and your phone both hold the secret. If either is stolen, the thief can produce valid codes indefinitely. This matters most if a large server database leaks.
The RFC says each user's key should be unique and ideally random, stored securely on the server with access limited to the processes that need it. How keys are delivered to users is outside its scope.
How it compares with passkeys
Passkeys use public-key cryptography rather than a shared secret, so a server breach does not expose anything that could generate your login. That is a design difference, not a judgement that one is right for every situation, and many sites support both methods. This article is general information, and the account help pages of each service describe its own options.
In short, TOTP works because two devices agree on a secret and on what time it is. The code is a short summary of both, which is why it can be checked without ever being stored.
Sources
Share
Keep reading
Related articles
How HTTPS and TLS Protect a Website Connection
HTTPS is ordinary web traffic wrapped in TLS. Here is what TLS protects, how a certificate fits in, and what changed in TLS 1.3.
How Passkeys Work: Signing In Without a Password
A passkey replaces your password with a pair of cryptographic keys. The private half never leaves your device, so there is no secret to type, steal or reuse.
What Is a Hash? SHA-256 vs SHA-1 Explained
What a cryptographic hash does, why SHA-256 is preferred to SHA-1, how to check a download against a published hash, and why hashes alone are wrong for storing passwords.