TOTP: what it stands for, and how six digits fall out of a clock

The short version

At enrollment a service hands you a secret, usually as a QR code. From then on both sides run the same arithmetic on their own: take the current Unix time, divide by 30 to get a step number, run that step number and the secret through HMAC, and squeeze the result down to six digits. Same secret plus same second means same digits, on any device, offline, forever — until someone changes the secret.

That independence is the point. There is no message to intercept, no server to be down, and no carrier in the path the way there is with an SMS code. The cost is that the secret is shared: whoever holds it can produce valid codes, which is why it matters more than the code it produces.

The algorithm, one step at a time

1. Turn the time into a counter. Take Unix time in seconds, subtract the epoch (zero, by convention), and divide by the time step — 30 seconds unless the service says otherwise. Integer division, so the counter holds still for the whole step and then ticks over.
2. Hash the counter with the secret. Encode the counter as eight bytes, big-endian, and compute HMAC-SHA1(secret, counter). SHA-256 and SHA-512 are permitted and a few services use them, but SHA-1 is the near-universal default, and its weaknesses as a collision-resistant hash do not apply to HMAC.
3. Pick four bytes out of the digest. This is the part that surprises people: the low four bits of the last byte give an offset, and the four bytes starting there are read as a 31-bit integer. It is called dynamic truncation, and it exists so that no part of the digest is systematically favoured.
4. Take the remainder. Modulo 10⁶ for six digits, padded with leading zeros. Eight-digit codes are the same operation with a bigger modulus, which is why a code can legitimately start with a zero and why dropping it fails.

The RFC 6238 test vectors

Appendix B of the specification publishes the values every implementation is expected to reproduce. The secret is the ASCII string 12345678901234567890 — in Base32, GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ — repeated as needed to fill the key length of the stronger hashes. Codes are shown at eight digits, with a 30-second step.

If you are checking your own code against these, note the detail that catches most people: the SHA-256 and SHA-512 rows use longer secrets — the same digit string continued to 32 and 64 bytes — not the 20-byte one. Feeding the short secret to SHA-512 produces numbers that look plausible and match nothing.

TOTP, HOTP, OTP, 2FA — which word means what

• OTP is the generic term: a one-time password, however it reached you. A code by text message is an OTP; so is the six digits in your authenticator.
• HOTP (RFC 4226) is the event-counter version. Each code advances a counter, so a device that generated codes the server never saw drifts ahead and needs resynchronising. Hardware tokens with a button still use it.
• TOTP (RFC 6238) replaces that counter with the clock. It is HOTP with the time step substituted for the event count — the rest of the construction is identical.
• 2FA is the policy, not the mechanism: two kinds of evidence instead of one. TOTP is one mechanism that satisfies it, and the wider picture is here.

Why the clock is the fragile part

Because the counter comes from the time, a device whose clock is wrong computes the code for a different step. Roughly thirty seconds of error is enough to produce digits the service rejects from a perfectly correct secret — and the error can be on either side, though servers are rarely the ones that drift.

Servers compensate by accepting a window, typically the step before and after, occasionally wider for services that expect users on bad clocks. That tolerance is also why a code can still work a few seconds after the digits on screen have changed. When codes are refused anyway, the clock is the first thing to check — the rejected-code guide walks through the rest.

What the secret looks like

The secret is bytes, but it is shown as Base32: the letters A–Z and the digits 2–7, in blocks of 16 or 32 characters. That alphabet exists so a key can be read aloud and typed without confusing 0 with O or 1 with l. Case does not matter, spaces do not matter, and = padding at the end is optional.

The QR code at enrollment is the same secret wrapped in a URI: otpauth://totp/GitHub:[email protected]?secret=JBSWY3DP…&issuer=GitHub. Every parameter that can vary — digits, period, algorithm — travels in that link, which is why importing it is more reliable than typing a key and guessing the rest.

Where TOTP stops helping

It defends against an attacker holding your password: leaked credentials, reuse across sites, guessing. That covers a large share of real account takeover, which is why it is worth the friction.

It does not defend against you giving the code away. A fake login page can collect password and code and use both on the real site inside the window. It does not help once malware is on the device. And unlike a passkey, the secret exists on the service’s side too, so a breach there can leak seeds for every account that enrolled. Phishing-resistant factors — passkeys, FIDO2 keys — close the first and the last of those, and are worth preferring where a service offers them.

Questions

What does TOTP stand for?

Time-based one-time password. The name is the whole design: a password that is valid once, derived from the current time and a secret both you and the service already hold.

What does TOTP mean on a login screen?

It means the site expects a code from an authenticator app rather than a text message or an email. Any app implementing RFC 6238 produces an acceptable code, because the standard is the only thing the service checks against.

Is TOTP the same as 2FA?

No. 2FA is the requirement for a second piece of evidence; TOTP is one way to satisfy it. SMS codes, push approvals, passkeys and hardware keys are alternative second factors, and a service can offer several of them at once.

What is the difference between TOTP and HOTP?

The counter. HOTP (RFC 4226) counts events, so the counter advances each time a code is produced, and generating codes you never use pushes your device out of step. TOTP (RFC 6238) uses the clock as the counter instead, which both sides already agree on without any messages passing between them.

How long is a TOTP code valid?

One time step, 30 seconds by default. In practice servers accept the neighbouring steps as well — commonly one either side — so a code usually survives somewhere between 30 and 90 seconds depending on how much drift the service tolerates.

Is TOTP secure?

It is strong against the thing it was designed for: an attacker who knows your password. It is weak against an attacker who can get you to read a code aloud or type it into a fake site, because a code relayed within its window is still valid. The shared secret is also stored by the service, so a breach at their end can expose seeds — which is why passkeys, where the secret never leaves your device, are stronger where they are offered.

What is RFC 6238?

The specification that defines TOTP, published in 2011 as an extension of HOTP. It fixes the time step, the HMAC construction and the truncation, and its Appendix B lists the test vectors implementations are checked against.

Why do two apps show the same code?

Because TOTP has no registration step. Any authenticator holding the same secret computes the same digits at the same moment, and the service cannot tell which device produced the code it receives.

Next