Generate and verify time-based one-time passwords (TOTP) from a base32 secret. Compatible with Google Authenticator and RFC 6238.
One-time passwords, RFC 6238. Generate the current TOTP for a base32 secret and validate a code you received. The counter is derived from the current time, so codes refresh every 30 or 60 seconds. Runs entirely in your browser.
TOTP is defined in RFC 6238 and is a thin layer over HOTP. Both sides hold the same secret, usually delivered once as a QR code and stored in an authenticator app. To produce a code, each side takes the current Unix time, divides it by the step size (30 seconds by default) to get a counter, computes HMAC-SHA1 of that counter under the secret, and truncates the result to the required number of digits.
Because the counter comes from the clock rather than from a message, nothing needs to travel between the two parties after enrolment. The server does not send a challenge and the app does not need network access — this is why authenticator apps work in airplane mode.
The HMAC output is 20 bytes, far more than a 6-digit code. Dynamic truncation uses the low nibble of the last byte as an offset, reads four bytes starting there, masks off the top bit to avoid sign problems, and takes that number modulo 10^digits. Using a variable offset rather than a fixed one means an attacker cannot concentrate analysis on a known slice of the digest.
Six digits is the near-universal default. Eight digits is supported by most apps and buys about two extra decimal digits of guessing resistance, which matters much less than rate limiting does — a 6-digit code has a 1-in-a-million chance per guess, so the real defence is locking out after a handful of failures.
Devices drift. Servers normally accept the code from the previous and next window as well as the current one, giving a ±30 second tolerance. Widening that window past a minute or two starts to meaningfully increase the attack surface and is usually a sign that a device clock needs fixing instead.
Two properties are worth remembering when you deploy this. A code stays valid for its whole window, so an intercepted code can be replayed within that window unless the server marks used counters as spent. And the secret is symmetric: whoever holds the server-side copy can generate valid codes forever, so it needs the same protection as a password database — encrypted at rest, never logged, never in a git repo.