What Is TOTP? How Time-Based One-Time Passwords Work

TOTP (Time-based One-Time Password) is an algorithm that generates a short numeric code — usually six digits — that changes every 30 seconds, derived from a secret key shared between a server and a device and the current time. It’s the mechanism behind most “authenticator app” multi-factor authentication codes: Google Authenticator, Authy, 1Password, and the built-in authenticators on modern phones all implement the same open standard, defined in RFC 6238.

How the algorithm actually works

TOTP is a small extension of an older standard, HOTP (HMAC-based One-Time Password). The core idea in both is: hash a shared secret together with a moving counter, and derive a short numeric code from the result.

1. Enrollment. The server generates a random secret key and shares it with the user’s device, typically encoded in a QR code. Both sides now hold the same secret.
2. Counter derivation. Instead of an incrementing counter (as HOTP uses), TOTP computes the counter from the current Unix time divided by a time step, usually 30 seconds. Every device with a synchronized clock computes the same counter value independently, with no network round trip required.
3. HMAC. The algorithm computes HMAC-SHA1(secret, counter), producing a 160-bit hash. Some implementations use SHA-256 or SHA-512, but SHA-1 remains the default for broad compatibility — this is one of the few places SHA-1 is still considered acceptable, since the attack relevant to TOTP’s security is brute-forcing the HMAC, not the collision weaknesses that killed SHA-1 elsewhere.
4. Truncation. A dynamic truncation step extracts a 31-bit chunk of the hash and reduces it modulo 10^6, producing a six-digit decimal code.
5. Verification. The server, holding the same secret, computes the expected code for the current time step (and usually the adjacent one or two steps, to tolerate clock drift) and checks for a match.

Because both sides derive the code independently from a shared secret and the current time, no data has to travel from server to device at verification time. This is what makes TOTP work offline, unlike SMS codes, which require a live network path.

Why time, not just a counter

HOTP’s event-based counter has a synchronization problem: if a user generates codes without submitting them (by tapping “next code” repeatedly, or if a request is dropped), the server’s counter and the device’s counter drift apart. Servers compensate with a “look-ahead window,” checking the next several counter values, but a large drift eventually locks the user out.

Time solves this more gracefully. Clocks drift by seconds, not indefinitely, and most devices sync via NTP. Servers only need a small tolerance window (commonly ±1 time step) rather than an open-ended lookahead, which keeps the guessing surface small for an attacker.

TOTP vs SMS codes

	TOTP	SMS one-time codes
Requires network at verification	No	Yes, on both legs
Vulnerable to SIM swapping	No	Yes
Vulnerable to secret theft	Yes, if seed is exposed	N/A (no persistent secret)
Works offline	Yes	No
Setup friction	QR code scan	Just a phone number
Interception risk	Low (nothing transmitted)	Higher (SS7, carrier-level attacks)

SMS codes remain common because they need no app, but they’re widely considered the weaker second factor: phone numbers can be ported to an attacker’s SIM through social engineering of a carrier, and SMS itself travels over signaling protocols with known interception weaknesses. TOTP’s shared secret never leaves the two endpoints during normal use.

Where TOTP falls short

TOTP is a major upgrade over passwords alone, but it isn’t the strongest available second factor:

• Phishing. A fake login page can prompt for a TOTP code just as easily as a password, then relay it to the real site within the 30-second window. TOTP verifies possession of a secret, not that the login attempt is on the legitimate site — it does nothing to bind the code to the correct origin.
• Seed exposure. If the shared secret is stolen — from a poorly secured server database, a phishing page that captures the QR code during setup, or malware on the device — an attacker can generate valid codes indefinitely without needing the physical device again.
• Backup and recovery. Losing the device that holds the secret is a real operational problem. Services typically mitigate this with backup codes or multiple registered devices, both of which are their own attack surface if handled carelessly.

Passkeys address the phishing weakness directly: they’re cryptographically bound to the origin that registered them, so a phishing site simply can’t get a valid response out of the browser’s passkey prompt, even from an unsuspecting user. TOTP remains far more widely deployed today because it needs no special hardware and works with any service that implements the RFC — but where it’s an option, a phishing-resistant factor is the stronger choice.

Implementing TOTP

If you’re adding TOTP to your own service rather than consuming someone else’s, a few practices matter:

• Generate secrets with a cryptographically secure random number generator, never a predictable seed.
• Store secrets encrypted at rest, not in plaintext — a stolen database with plaintext TOTP seeds is equivalent to a stolen set of infinite valid codes.
• Rate-limit verification attempts. A six-digit code has only a million possibilities; without rate limiting, brute force becomes viable within the code’s validity window.
• Allow a small time-step tolerance for clock drift, but don’t widen it further than necessary — every extra step you accept widens the brute-force window.

The takeaway

TOTP turns a shared secret and the current time into a short-lived, offline-verifiable code, refreshed every 30 seconds. It closes off SIM-swapping and network-interception attacks that plague SMS codes, at the cost of remaining phishable and dependent on how carefully the underlying secret is stored. For most applications it’s a solid, low-friction second factor; for the highest-value accounts, pairing it with or replacing it entirely with passkeys removes the phishing risk that TOTP alone can’t solve.