HOTP Generator

Generate counter-based one-time passwords using RFC 4226 HOTP.

Overview

Generate a counter-based one-time password from a shared secret and counter value using the RFC 4226 HOTP algorithm. The output is the truncated decimal code (6 or 8 digits) that an authenticator would display for the same inputs.

It's for developers implementing or debugging two-factor authentication - especially HOTP-based flows (Yubikey OTP, older corporate 2FA) where the counter is a discrete event, not a clock. Reach for it when validating a server-side HOTP implementation, generating a fixed code for unit tests, or troubleshooting why a hardware token has drifted out of sync.

How it works

HOTP is defined in RFC 4226. The algorithm is:

Treat the counter as an 8-byte big-endian integer.
Compute HMAC-SHA1(secret, counter) to get a 20-byte hash.
Dynamic truncation: take the low nibble of the last byte as offset O; read 4 bytes starting at offset O, mask the top bit, and treat the result as a 31-bit integer.
Modulo by 10^digits to get the OTP.

The secret is typically encoded in Base32 (matching otpauth:// URIs); the counter increments on each successful authentication, so server and client must stay in lockstep.

Examples

Reference test vector from RFC 4226 (secret 12345678901234567890, counter 0):
```
Code (6 digits): 755224
```
Counter 1, same secret:
```
Code: 287082
```
8-digit variant (counter 0):
```
Code: 84755224
```

Typical Base32 secret from otpauth://:

JBSWY3DPEHPK3PXP, counter=1 -> 996554 (example, depends on impl)

FAQ

What's the difference between HOTP and TOTP?

TOTP (RFC 6238) replaces the counter with floor(unix_time / step), so codes rotate on a 30 second cycle. HOTP only advances on use.

Why does my hardware token's counter drift?

If the token generates a code that isn't sent to the server, its counter advances while the server's doesn't. Servers usually accept a small "look-ahead window" (commonly 10-50 codes) to resync.

Is HMAC-SHA1 still safe here?

For HOTP/TOTP the use of SHA-1 is constrained (output is truncated to 31 bits and the secret is high-entropy), so the underlying weaknesses don't break the scheme. SHA-256 variants exist for forward compatibility.

How long should the secret be?

RFC 4226 recommends at least 128 bits (16 bytes). Common authenticator apps require Base32-encoded secrets, padding to multiples of 5 bits.

Try HOTP Generator