In one sentence
TOTP is the algorithm behind the rotating six-digit code in Google Authenticator and similar apps — it hashes a shared secret together with the current 30-second time step so the phone and the server independently arrive at the same short-lived number.
Why it matters
A password is a secret you send; a TOTP code is a secret you prove you hold without sending it. That is what makes it a genuine second factor: even if an attacker phishes your password, they do not have the seed inside your authenticator app, so they cannot produce the current code. TOTP turns "something you know" into "something you know and something you have".
It is also refreshingly boring in the best way — no SMS to intercept, no network round-trip, no vendor. The phone and the server share one secret at enrolment and never talk again; both just do the same maths against the clock. That offline, standardised design (RFC 6238) is why the same app works for hundreds of unrelated services.
How the code is generated
TOTP is HMAC plus a clock. At enrolment the service gives you a random secret, usually Base32-encoded and delivered as a QR code. To produce a code:
- Take the current Unix time, divide by the period (30 seconds by default) to get a counter
T. - Compute
HMAC-SHA1(secret, T)(SHA-256/512 are allowed but SHA-1 is what almost every app uses). - Truncate the HMAC down to a 6-digit number (the RFC's dynamic-truncation step).
Because both sides use the same secret and the same clock, they get the same digits — for 30 seconds. The enrolment QR is really an otpauth://totp/ URI carrying the issuer, account, secret, algorithm, digit count and period. The only shared state is the secret; everything else is public.
Try it yourself hands-on
See how a QR code becomes a rotating number, and why servers must forgive a little clock drift.
- Open the TOTP Generator, click Random to mint a Base32 secret, and set an issuer and account (e.g.
CyberRamen/demo@example.com). Watch the six-digit code and its countdown — it rolls over every 30 seconds. The Provisioning URI it builds (otpauth://totp/…) is exactly what an authenticator app scans. - Change the Period to 60s or the Algorithm to SHA-256 and note the code changes: if a server and app disagree on either, every code will read as wrong. This is the number-one "my 2FA is broken" cause.
- Use Verify TOTP Code and type last window's code a beat late. It still validates, reporting a match on the previous window — that is the ±1 window servers allow so a slightly slow phone clock does not lock you out. Type a random number and it matches no window.
- To see the primitive underneath, the HMAC Generator computes the same HMAC-SHA1 that TOTP truncates into digits.
Result: you understand why enrolment is a QR (the secret), why codes rotate, and why "off by one window" is a feature, not a bug.
Common misreadings
- TOTP is phishing-resistant only up to a point. A real-time phishing proxy can relay a code within its 30-second life. For genuine phishing resistance, passkeys / FIDO2 bind the login to the site; TOTP does not.
- The secret is the whole ballgame. If the seed leaks (screenshot of the QR, secret stored in plaintext), the second factor is gone. Treat it like a password and never log or email it.
- A too-wide window weakens it. Accepting many windows to "help" users defeats the point; ±1 (about 90 seconds total) is the usual, sane allowance.