How authenticator app codes work: TOTP, explained

Two-factor codes look like magic: a six-digit number that changes every half minute on your phone and is somehow known to a website you're not connected to. The mechanism is small enough to explain in a page — the TOTP generator implements it in a few lines — and understanding it changes how you back up your accounts.

The shared secret

When you enable two-factor authentication, the site generates a random secret key, typically 20 bytes, and shows it to you once — as a QR code and usually as a string of letters and digits in Base32 (A–Z and 2–7). Your authenticator app stores it; the site stores it. From then on both sides possess the same secret and neither ever transmits it again. That is the entire trust relationship: whoever has the secret can produce the codes, which is why the setup screen warns you not to share it and why the codes are a "something you have" factor — you have the phone the secret is on.

The clock and the 30-second window

The other input is time. Both sides take the current Unix time (seconds since 1970), divide by 30 and drop the fraction, giving a counter that increases once every 30 seconds and is the same everywhere on Earth. No connection is needed because both sides can read a clock. It also explains the failure everyone eventually hits: if the phone's clock is minutes off, its counter is different and every code is rejected. Servers usually accept the previous and next window to allow a little drift — about a minute — and most phones set their clock from the network, so it rarely bites.

From secret and time to six digits

The counter is fed with the secret into HMAC-SHA1, a keyed hash: 20 bytes out that look random and cannot be reversed to reveal the secret. The standard (RFC 6238, TOTP, building on RFC 4226, HOTP) then takes four bytes from the hash at an offset given by its last nibble, interprets them as a number, and keeps the last six digits. Both sides compute the same thing and compare. The digits are not a password and carry no information about the secret; an attacker who sees one code learns nothing useful about the next, and a code is useless after its window. Sites can choose 8 digits, a 60-second period or SHA-256, which is why the generator exposes those options; the defaults are what almost everything uses.

What the setup QR code contains

The QR code is just a URL in the otpauth scheme: otpauth://totp/Site:you@example.com?secret=JBSWY3DP…&issuer=Site, optionally with digits, period and algorithm. Scanning it saves the label and the secret; nothing else happens. That is why the "can't scan? enter this key" text is equivalent — it is the same secret — and why a screenshot of a setup QR code is as sensitive as a password. How QR codes actually work explains the code itself.

Backups, lost phones and honest risks

Because the secret is everything, losing the phone without a backup locks you out. Options, in order of safety: the recovery codes the site offered at setup (print them, store them separately); an authenticator that backs up encrypted (most do now); or keeping the secret in a password manager, which many managers can also use to generate codes. Whatever you do, do it at setup, not after the phone breaks. Honest risks: TOTP stops password-only attacks but not real-time phishing (a fake site can relay your code within its 30 seconds) — passkeys and hardware keys fix that; and a web page that computes codes is a fallback and a testing tool, not a home for your secrets. The password generator covers the first factor; How long should a password be? the reasoning.