RFC 6238 / START HERE
Time-based one-time passwords, before the details
TOTP means Time-Based One-Time Password.
It is an algorithm that lets an authenticator and a server compute the same short decimal code using a shared secret and the current time. The authenticator is called the prover; the server is the verifier. HMAC is a keyed computation that mixes the secret with a counter derived from time.
The idea in one picture
Clock → counter
Shared-secret HMAC
Digits + replay gate
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
HOTP in RFC 4226 advances an event counter. RFC 6238 instead derives that moving counter from Unix time, making a code stable for a short time step. It defines the algorithm and validation guidance, not a QR enrollment format or a complete login protocol. This Informational publication has no formal updates or obsoletions in the checked RFC Editor metadata.
A familiar example
An authenticator generates a code at second 59; with a 30-second step, it uses counter 1. A server receiving it at second 60 uses counter 2 and may check the bounded preceding step for transmission delay. After a successful check, it must reject reuse of that OTP. This guide uses published test secrets only; never use those secrets for a real account.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Turn time into a moving counterA prover is the authenticator that generates a code. A verifier is the server checking it. Both turn Unix time, measured in seconds, into the same integer time-step counter T. They do not exchange a timestamp for every calculation.→
- HMAC and dynamic truncationHMAC is a keyed message authentication code: it mixes the shared secret K with the eight-byte counter T. Dynamic truncation then selects four digest bytes and clears one bit to make a nonnegative 31-bit integer.→
- Reduce to digits and keep leading zerosA short code is a decimal string, not the whole digest. Reduce the 31-bit integer modulo 10 raised to the agreed digit count, then pad on the left with zeros to that width.→
- Compare the three permitted HMAC variantsRFC 6238 permits HMAC-SHA-256 and HMAC-SHA-512 in addition to the HOTP HMAC-SHA-1 building block. The hash and secret must match the setup used by both endpoints.→
- Bound delay and reject replayThe verifier recomputes codes using its own clock and the provisioned secret. A small, explicitly configured window can cover a code generated just before a boundary and received just after it. Matching alone does not allow reuse.→
- Provision and protect the shared secretThe prover and verifier need matching secret material before they can compute the same codes. Time is public; the secret is what makes the computation specific to the prover. RFC 6238 defines the algorithm, not a QR enrollment format.→
This introduction explains RFC 6238 (2011). Read the original RFC ↗