TOTP

TOTP (Time-based One-Time Password) is the algorithm behind Google Authenticator, Authy, 1Password’s TOTP feature, and most software-based 2FA. Defined in RFC 6238 (2011).

How it works: at enrollment, the server and the authenticator app exchange a shared secret (typically a 160-bit value encoded as a base32 string or QR code). To generate the current OTP, both sides:

1. Take the current Unix time, divided by the period (default 30 seconds), rounded down.
2. Compute HMAC-SHA1 of that counter using the shared secret.
3. Truncate to 6 digits.

Both sides produce the same code without communicating. The 30-second window plus a ±1-window tolerance handles clock drift. The shared secret never leaves the device after enrollment.

TOTP is enormously better than SMS OTP (no SIM-swap exposure) but doesn’t defeat phishing on its own — an attacker who phishes the current code can replay it within the window. WebAuthn / passkeys are the next-generation answer.

The shared-secret provisioning format: the QR codes shown by Google Authenticator, GitHub, AWS IAM, and others encode an otpauth://totp/Issuer:label?secret=BASE32SECRET&algorithm=SHA1&digits=6&period=30 URI. The scheme is a 2011 Google convention rather than a formal IETF spec, but every major authenticator app supports it. Some services (Microsoft, Steam) extend the digits to 7-8 or shorten the period to 15 seconds for higher entropy at the cost of a tighter window. Read the QR with a generic QR-reader app once to capture the secret, then back it up offline — losing access to the authenticator without that backup means going through account-recovery.

SHA-1 in a 2026 spec — is it safe? Yes, in this context. TOTP’s use of HMAC-SHA1 is not vulnerable to the SHA-1 collision attacks that retired the hash for TLS certificates; HMAC depends on SHA-1’s pre-image resistance, which remains intact. RFC 6238 also allows SHA-256 and SHA-512, but virtually every authenticator app defaults to SHA-1 for cross-vendor compatibility. If the provisioning URI specifies algorithm=SHA256, the verifier and authenticator must both support it — many older apps will silently break. Related: OTP, SHA-256, JWT.

Worked example: deriving a code

Shared secret (base32) JBSWY3DPEHPK3PXP. Suppose the current Unix time is 1700000000. Counter = floor(1700000000 / 30) = 56666666. Pack the counter as an 8-byte big-endian integer, compute HMAC-SHA1(secret, counter) producing a 20-byte digest, take the low-order nibble of the last byte as offset o, read 4 bytes starting at o, mask the high bit, and mod by 10⁶. The result is a 6-digit code such as 359152. At t = 1700000030 the counter advances by 1 and the code rotates. Twelve seconds of clock skew between server and phone is harmless; sixty seconds usually fails verification unless the server widens the tolerance window.

When TOTP is the right choice

TOTP makes sense as a second factor anywhere an attacker who already has the password should still be blocked: bank logins, code hosting, cloud consoles, email. It does not replace a password (the secret is symmetric — server compromise reveals every user’s seed) and it does not stop real-time phishing kits like evilginx that proxy the login flow. For phishing-resistant auth, prefer WebAuthn / passkeys, which cryptographically bind the credential to the legitimate origin. Reference: NIST SP 800-63B — Digital Identity Guidelines (Authentication), which categorises TOTP as a memorised-secret-equivalent “something you have” AAL2 authenticator.