TOTP vs HOTP: how authenticator codes work

Published 19 September 2026. About 6 minutes.

Every authenticator app, KeyNesta included, generates codes from two open standards: TOTP (time-based one-time passwords, RFC 6238) and HOTP (HMAC-based one-time passwords, RFC 4226). Knowing how they work explains most of the everyday questions: why codes work without internet, why a wrong clock breaks them, and why a QR code must be treated like a password.

The shared secret

When you enable 2FA on a service, it shows a QR code. That QR encodes an otpauth:// link containing a random secret (written in base32), plus the issuer, your account name, and a few parameters: the hash algorithm, the number of digits, and either a time period or a counter. Your app stores the secret; the service stores the same secret. From then on, nothing is transmitted when you generate a code. Both sides compute it independently.

That is why the QR is sensitive: anyone who scans it can generate your codes forever. It is also why KeyNesta decodes imports on your device and never uploads them.

And it is why two devices holding the same secret show identical codes, with no pairing step to look for and no device list on the account: an authenticator app on two devices covers the three routes to a second device and what each one costs.

TOTP: codes from the clock

TOTP takes the current time, divides it into steps (30 seconds by default), and feeds the step number and the secret into an HMAC. The result is truncated to a short number, usually six digits. Because the input changes every 30 seconds, so does the code. Your app and the service agree on the code only because they agree on the time.

• Clock drift: services usually accept a code from one step before or after the current one, so a phone that is a few seconds off still works. Minutes off, and every code is rejected. The fix is to let the device set its clock automatically. When the clock is already correct and a code is still refused, 2FA code not working covers the causes that survive a correct clock.
• Parameters: the default is SHA-1, six digits and 30 seconds. Some services use SHA-256 or SHA-512, seven or eight digits, or a longer period. The QR carries these choices; a compliant app follows them.

HOTP: codes from a counter

HOTP is the older standard. Instead of time, it uses a counter that increases every time you generate a code. Your app and the service must stay in step: if you generate codes without using them, the service looks a few counters ahead to resynchronise, but only up to a limit. HOTP shows up in hardware tokens and a few banks; most websites use TOTP because a clock is easier to keep in sync than a counter.

Which one should you use?

You do not choose. The service that issues the QR decides, and the QR tells your app which standard and which parameters to use. Both are equally secure when implemented correctly; the security comes from the secret and the HMAC, not from the choice of time versus counter.

Why codes work offline

Generating a code needs only the secret and either the clock or the counter, both of which are on your device. No network, no account, no server. This is also why an authenticator app should never need internet access to show a code; if one does, something other than the standard is going on.

It is also the difference from SMS codes, which are sent to you over the phone network at login time and can be redirected by a SIM swap. Authenticator app vs SMS covers what that changes, and what neither kind of code protects against.

What KeyNesta does with all this

• Reads every parameter from the otpauth:// link: algorithm (SHA-1, SHA-256, SHA-512), six to eight digits, custom periods, and HOTP counters.
• Generates codes on the device and shows the remaining seconds for TOTP entries.
• Stores the secrets encrypted with AES-256-GCM; see how KeyNesta encrypts your 2FA codes.
• Imports the same data from Google Authenticator, Aegis and 2FAS, JSON and CSV.

Frequently asked questions