TOTP and HOTP, Explained

After reading this you will know how a 6-digit authenticator code is computed from a shared secret, how to reproduce one by hand, and which mistakes silently break two-factor login.

A TOTP code is not random. It is a deterministic function of two inputs: a secret both sides know, and the current 30-second time step. Given the same secret and the same time, your phone and the server compute the same 6 digits independently, with no message passing between them. That is the whole trick.

Here is the hook. The secret JBSWY3DPEHPK3PXP is Base32 for the ASCII bytes Hello!\xDE\xAD\xBE\xEF. At Unix time 59 seconds, the standard RFC 6238 test vector produces the code 287082. Change the time to the next 30-second window and the code changes completely. Nothing about 287082 tells you the next code unless you hold the secret.

What HOTP and TOTP actually are

HOTP (RFC 4226) is the base construction: an HMAC-based one-time password driven by a counter. Each time you use a code, both sides increment the counter, so the same secret yields a different code each step. TOTP (RFC 6238) is HOTP with one substitution: instead of a manually incremented counter, it uses the current time divided into fixed windows.

Shared secret

A random key, usually 16 to 32 bytes, encoded in Base32 for display. Both the authenticator and the server store it.

Counter

For HOTP, an integer that increments on each use. For TOTP, the number of time steps since the Unix epoch.

Time step

The window length, almost always 30 seconds, written T_0 = 0, X = 30.

Digits

How many decimal digits to keep, usually 6, sometimes 7 or 8.

When to use it, and when not

Use TOTP as a second factor: a code the user types in addition to a password. It defends against a leaked or guessed password, because the attacker also needs the current code, which needs the secret. It runs offline, which is why it survives on a phone in airplane mode.

Do not use TOTP as a single factor. A 6-digit code has one million possible values, and if you allow unlimited guesses an attacker can brute force one window. Rate limiting matters: 10 attempts per code window keeps the success probability at 10 / 10^6 = 10^{-5} per window. Do not use TOTP where you cannot protect the secret at rest, and do not treat SMS codes as equivalent, since those travel over a channel an attacker can intercept or redirect.

The formula and the intuition behind it

Start with the counter. For TOTP, the counter C at Unix time t is the number of whole time steps elapsed:

Here t is the current Unix time in seconds, T_0 is the epoch offset (0), and X is the step length (30). At t = 59 this gives \lfloor 59 / 30 \rfloor = 1.

Next, HMAC the 8-byte big-endian counter under the secret K:

H is a 20-byte digest. It looks random and cannot be reversed to recover K, which is why holding one code does not leak the secret. The last step, dynamic truncation, squeezes those 20 bytes down to a number.

Here d is the digit count (6). The truncation reads the low 4 bits of the last byte of H as an offset o between 0 and 15, takes 4 bytes starting at o, masks off the top bit to keep the result positive, then reduces modulo 10^6. The offset step is what makes truncation depend on the data itself rather than always reading the same position.

A worked example you can reproduce

Reading the live code and its countdown

The tool shows the current code and a countdown. The countdown is 30 - (t \bmod 30) seconds. At t = 59 that is 30 - 29 = 1 second left, so the code 287082 is about to roll over to the code for counter 2.

Servers usually accept a small window of adjacent counters to absorb clock skew. A common setting accepts the previous and next step, so three windows total. That widens the brute-force target by a factor of 3, which is why the accepted window is kept small.

The otpauth URI and QR strings

Authenticator apps import a secret through an otpauth:// URI, which is what a QR code encodes. The shape is:

The secret parameter is the Base32 string, with no padding characters. The period is the step in seconds, digits is the code length, and algorithm can be SHA1, SHA256, or SHA512. Most apps default to SHA1 and 6 digits and quietly ignore other choices, so if you set algorithm=SHA256 and the app assumes SHA1, the codes will never match. Test the imported code against the server before you rely on it.

Common mistakes

The failure modes are almost always mechanical, not cryptographic.

• Wrong Base32. The secret is Base32 (RFC 4648, alphabet A-Z and 2-7), not Base64 and not hex. Feeding a hex string as if it were Base32 decodes to the wrong bytes and every code is wrong.
• Clock skew. TOTP trusts the device clock. If a server is 40 seconds fast, it computes the next window's code and rejects the correct one. Keep both clocks synced to NTP.
• Algorithm mismatch. SHA1 remains the default for TOTP despite being weak for collision resistance, because HMAC-SHA1 has no practical break and interoperability matters. Do not switch to SHA256 unless both ends agree.
• Reusing a code. Codes are one-time within their window. A server that accepts the same code twice loses the replay protection that the counter provides.

Related tools

Once a user proves possession of a factor, a server often issues a signed session token. If you are building the token side of that flow, the JWT Builder & Signer creates and signs JSON Web Tokens with HS256, HS384, and HS512, which pairs naturally with a TOTP login step.

Related tools

JWT Builder & Signer

Build and sign JSON Web Tokens (HS256/384/512).

AES Encryption

Encrypt and decrypt text with AES-GCM or AES-CBC.

Cryptographic Key Generator

Random keys, IVs, salts and API tokens from a CSPRNG.

Enigma Machine Simulator

Operate a full Enigma I — rotors, plugboard, lamp board — and watch each letter travel the wiring.

Proof-of-Work Mining Simulator

Mine blocks with real SHA-256, tamper with a chain, and see why difficulty and 51% attacks work the way they do.

RSA Key Pair Generator

Generate 2048/3072/4096-bit RSA keys in PEM format.