TOTP vs HOTP: How One-Time Passwords Work

TOTP and HOTP are the standards behind many six-digit authentication codes. When a service asks for a code from Google Authenticator, 1Password, Authy, or a hardware token, it is often using one of these two algorithms. The difference is simple: TOTP uses time; HOTP uses a counter.

That difference affects how codes are generated, how devices stay synchronized, and how you recover from a missed login attempt. You can experiment with both formats using the free TOTP/HOTP generator on checksec, without uploading a secret to a server.

What is HOTP?

HOTP, defined in RFC 4226, is a hash-based one-time password algorithm. It combines a shared secret with an incrementing counter:

HOTP(secret, counter) = truncate(HMAC-SHA-1(secret, counter))

The HMAC result is truncated and reduced to a six- or eight-digit code. The server and authenticator must agree on the counter value. After a successful login, both sides increment it.

The counter creates a practical synchronization problem. If a user presses the button three times but only submits the third code, the server still expects the next counter value unless it supports a look-ahead window. Implementations usually accept a small range of future counters, then resynchronize after a valid code.

HOTP is useful when authentication events are discrete. Hardware tokens that generate a code when a button is pressed are a common example. It is less convenient for phone authenticator apps because the user and server need to keep their counters aligned.

What is TOTP?

TOTP, defined in RFC 6238, replaces HOTP’s counter with the current time divided into fixed steps. The usual time step is 30 seconds:

counter = floor(current Unix time / 30)
TOTP(secret, time) = HOTP(secret, counter)

The shared secret remains the same, but the generated code changes automatically every time step. The server typically accepts the current code plus one adjacent time window to account for clock drift and network delay.

TOTP is popular because it is easy to deploy with a QR code. The QR code encodes an otpauth:// URI containing the account name, issuer, secret, digits, algorithm, and period. An authenticator app scans that URI and generates codes locally. No SMS provider or network connection is required after setup.

Try a known test secret in the TOTP generator and compare the code as the clock moves into the next 30-second window. For production secrets, use a trusted authenticator app and never paste an active secret into an online tool.

TOTP vs HOTP at a glance

Both algorithms depend on the secrecy of the shared key. The code itself is not a password replacement; it is a second factor derived from a secret held by the server and the authenticator.

How to implement TOTP safely

Store the shared secret encrypted at rest and restrict access to the authentication service. Do not log the secret, QR code URI, or submitted OTP. Compare codes in constant time, reject a code after successful use where your threat model requires replay protection, and rate-limit failed attempts.

Allow a small time drift window, but do not accept unlimited historical codes. A large window makes clock problems less visible while giving an attacker more valid guesses. Synchronize server clocks with a reliable time source and record the last accepted time step for each account if replay resistance matters.

During enrollment, require the user to confirm a generated code before enabling the factor. Provide recovery codes and a documented account-recovery process. Recovery is part of the authentication design; a strong TOTP implementation can still be undermined by an email-only reset flow.

Protect the secret during setup

The otpauth:// URI contains the credential. Treat it like a password. Do not put it in screenshots, support tickets, analytics URLs, or source control. If a secret is exposed, revoke it and enroll a new factor rather than relying on the short lifetime of the six-digit codes.

For related signing and verification concepts, the HMAC generator lets you inspect how a secret key changes a message authentication code. For a standards reference, use the TOTP/HOTP generator with non-production test secrets.

Next step: choose TOTP for most app-based 2FA deployments, use HOTP when event counters fit the device, and design enrollment, recovery, rate limits, and secret storage together.

More posts →