About

Misconfigured OTP parameters cause authentication lockouts. A wrong hash algorithm, an off-by-one counter, or a clock drift beyond the tolerance window means denied access and frustrated users. This tool computes HMAC-based One-Time Passwords per RFC 4226 (HOTP) and RFC 6238 (TOTP) entirely in your browser using the Web Crypto API. It accepts a Base32-encoded secret K, selects the hash function H ∈ {SHA-1, SHA-256, SHA-512}, and applies dynamic truncation to the resulting HMAC digest. For TOTP, the counter C is derived as (T − T₀)X where X defaults to 30 s. No server calls are made. Your secret key never leaves this page.

Pro tip: Most authenticator apps only support SHA-1 with 6 digits and 30-second periods. If you configure SHA-256 or SHA-512, verify your authenticator actually supports it. Many silently fall back to SHA-1, producing mismatched codes. This tool lets you validate exact parameter combinations before deploying to production. Note: TOTP accuracy depends on your device clock. A drift exceeding 30 s from UTC will produce codes that fail server-side validation unless the server implements a look-ahead/look-behind window.

Formulas

HOTP computation per RFC 4226:

HOTP(K, C) = Truncate(HMAC−H(K, C)) mod 10^d

Where Truncate applies dynamic truncation. Let HS = HMAC−H(K, C). The offset o is the low-order 4 bits of the last byte of HS:

o = HS[len(HS) − 1] ∧ 0x0F

Extract 4 bytes from HS at offset o, mask the most significant bit:

P = ((HS[o] ∧ 0x7F) << 24) | (HS[o+1] << 16) | (HS[o+2] << 8) | HS[o+3]

Final code: P mod 10^d, zero-padded to d digits.

For TOTP (RFC 6238), the counter C is time-derived:

C = floor(T − T₀X)

Where K = shared secret key (Base32-decoded), C = counter value (8-byte big-endian), H = hash algorithm (SHA-1, SHA-256, or SHA-512), d = number of digits (6 - 8), T = current Unix time in seconds, T₀ = epoch start (usually 0), X = time step in seconds (default 30).

Reference Data

Parameter	RFC Default	Google Authenticator	Microsoft Authenticator	Authy	Notes
Algorithm	SHA-1	SHA-1 only	SHA-1 / SHA-256	SHA-1 only	RFC 6238 supports SHA-256/512
Digits	6	6	6	6 / 7 / 8	Range: 6 - 8
Period (X)	30 s	30 s	30 s	30 s	Some services use 60 s
Secret encoding	Base32 (RFC 4648)	Base32	Base32	Base32	Padding optional
Min secret length	128 bits	80 bits	128 bits	128 bits	RFC recommends 160 bits for SHA-1
Recommended secret (SHA-1)	160 bits (20 bytes)	-	-	-	32 Base32 chars
Recommended secret (SHA-256)	256 bits (32 bytes)	-	-	-	52 Base32 chars
Recommended secret (SHA-512)	512 bits (64 bytes)	-	-	-	103 Base32 chars
Counter size (HOTP)	8 bytes	N/A	N/A	N/A	Big-endian unsigned 64-bit
Look-ahead window	1 - 3 steps	1	1	1	Server-side tolerance
Resync threshold (HOTP)	10 steps	-	-	-	RFC 4226 §7.4
URI scheme	`otpauth://`	Yes	Yes	Yes	De facto standard
T₀ (epoch)	Unix epoch (0)	0	0	0	Seconds since 1970-01-01
HMAC output (SHA-1)	20 bytes	-	-	-	Truncated to 4 bytes
HMAC output (SHA-256)	32 bytes	-	-	-	Truncated to 4 bytes
HMAC output (SHA-512)	64 bytes	-	-	-	Truncated to 4 bytes
RFC 4226 test vector secret	`12345678901234567890` (ASCII)	-	-	-	Base32: `GEZDGNBVGY3TQOJQ`
RFC 6238 test vector (SHA-1)	Counter 1 → 287082	-	-	-	Time = 59 s

Frequently Asked Questions

Three common causes: (1) Your device clock is out of sync with UTC. TOTP divides Unix time by the period, so even a 30-second drift produces a different counter value. Sync your clock via NTP. (2) The hash algorithm mismatches. Google Authenticator only supports SHA-1. If you configured SHA-256 in your server, Google Authenticator silently uses SHA-1 and produces a different code. (3) The secret was incorrectly encoded. Ensure you use the raw Base32 string without spaces or hyphens. Padding characters (=) are optional per RFC 4648 but some implementations choke on them.

RFC 4226 Section 4 requires the shared secret to be at least 128 bits (16 bytes, 26 Base32 characters). However, the RFC recommends matching the HMAC output length: 160 bits (20 bytes) for SHA-1, 256 bits (32 bytes) for SHA-256, and 512 bits (64 bytes) for SHA-512. Keys shorter than the hash output are zero-padded internally by HMAC, which does not reduce security but wastes entropy potential. Keys longer than the hash block size (64 bytes for SHA-1/256, 128 bytes for SHA-512) are first hashed, which is functionally equivalent but adds unnecessary computation.

A server typically accepts codes from counter values C−1, C, and C+1 (a window of 1 step in each direction). This compensates for clock drift and network latency. With a 30-second period, that gives roughly a 90-second acceptance window. Increasing the window to 2 steps (150 seconds) reduces lockouts but increases the attack surface. Each additional step doubles the probability of a brute-force match from 1/10^d to n/10^d where n is the total window size.

Yes. HOTP increments the counter on each generation. If a user generates codes without submitting them, their counter advances beyond the server's look-ahead window (typically 10 steps per RFC 4226 Section 7.4). Beyond that threshold, the server cannot find a matching counter value and the token is effectively locked. Recovery requires server-side counter reset. TOTP avoids this because its counter is derived from time, not usage.

Yes, for this specific use case. SHA-1 collision attacks (SHAttered, 2017) target the compression function to find two inputs with the same hash. HMAC-SHA-1 uses the hash as a keyed PRF, which is resistant to collision attacks. The HMAC security proof requires only second-preimage resistance, which SHA-1 still provides. RFC 6238 nonetheless recommends SHA-256 or SHA-512 for new deployments as a defense-in-depth measure. The practical risk of HMAC-SHA-1 compromise for OTP is negligible at current computational capabilities.

The time step X directly affects usability and security. A shorter period (e.g., 15 seconds) increases security by narrowing the valid window but frustrates users who cannot type the code fast enough. A longer period (e.g., 60 seconds) is more forgiving but each code is valid longer, increasing exposure to shoulder-surfing. Most authenticator apps hardcode 30 seconds. If your server issues otpauth:// URIs with period=60, some apps ignore it and default to 30, causing mismatched codes. Always verify client-side support before deploying non-standard periods.