TOTP didn't appear out of nowhere — it's a direct extension of HOTP (HMAC-based One-Time Password, RFC 4226, 2005), which used an incrementing counter instead of time. The Initiative for Open Authentication published TOTP as RFC 6238 in 2011, swapping that counter for the current Unix time divided into 30-second steps; Google Authenticator, released the same year, is largely what made the algorithm a household mechanism rather than an enterprise niche.
A shared secret plus time
During setup, the server and the authenticator app exchange a single shared secret key (that's exactly what's encoded in the QR code). From then on, both sides independently compute an HMAC from that secret and the current unix time, rounded to a 30-second interval — arriving at the same code without communicating with each other.
Why this works offline
Since the code is computed locally from the secret and the device's system clock, the authenticator app needs no network connection to generate a code. The only requirement is that the server's and phone's clocks stay synchronized within a small allowed tolerance (usually ±30–60 seconds) — which is also the entire reason RFC 6238 specifies a time step in the first place, rather than something purely event-based like HOTP.
Why the code changes every 30 seconds
The short time interval limits the window during which an intercepted code stays valid, reducing the risk of it being reused by an attacker. The server typically accepts the current interval plus one previous interval to account for a small network delay when entering the code.
Why you'd need this
- Understanding the mechanics of two-factor authentication when setting up or troubleshooting authenticator apps.
- Testing your own TOTP implementation while building an authentication system.
- Generating codes for automated testing without manually entering them from a phone.
What TOTP doesn't protect against
TOTP reliably protects against a stolen password used separately from the code, but not against real-time phishing: if a victim enters both their password and the current TOTP code on a fake site, an attacker can instantly use both values on the real site while the code is still valid. Only hardware keys following the FIDO2/WebAuthn standard, which are cryptographically bound to a specific domain, protect against this kind of attack.