Totp Token Calculator
Generate time-based one-time passwords (TOTP) from a secret key for two-factor authentication. Enter values for instant results with step-by-step formulas.
Formula
TOTP = Truncate(HMAC-SHA1(Secret, floor(Time / TimeStep))) mod 10^Digits
The TOTP algorithm divides the current Unix timestamp by the time step to produce a counter, applies HMAC-SHA1 using the shared secret, then truncates the hash output to produce a numeric code with the specified number of digits. The verification window extends acceptance to adjacent time steps.
Worked Examples
Example 1: Standard TOTP Configuration Analysis
Problem: A company uses standard TOTP with 20-byte secrets, 30-second steps, 6-digit codes, window size 1, for 1,000 users averaging 5 logins per day.
Solution: Total possible codes = 10^6 = 1,000,000\nValid codes per window = 1 + 2(1) = 3\nBrute-force odds = 3/1,000,000 = 0.0003%\nCodes generated per day = 86,400/30 = 2,880\nSecret entropy = 20 x 8 = 160 bits\nBase32 secret length = ceil(160/5) = 32 characters\nDaily auth events = 1,000 x 5 = 5,000\nExpected false accepts/day = 5,000 x 0.000003 = 0.015
Result: 3-in-a-million brute-force odds | 160-bit secret entropy | 5,000 daily auth events | 0.015 expected false accepts per day
Example 2: High-Security 8-Digit Configuration
Problem: A financial institution needs higher security using 32-byte secrets, 60-second steps, 8-digit codes, window size 0, for 50,000 users with 3 logins per day.
Solution: Total possible codes = 10^8 = 100,000,000\nValid codes per window = 1 + 2(0) = 1\nBrute-force odds = 1/100,000,000 = 0.000001%\nCodes generated per day = 86,400/60 = 1,440\nSecret entropy = 32 x 8 = 256 bits\nBase32 secret length = ceil(256/5) = 52 characters\nDaily auth events = 50,000 x 3 = 150,000\nExpected false accepts/day = 150,000 x 0.00000001 = 0.0015
Result: 1-in-100-million brute-force odds | 256-bit secret entropy | 150,000 daily events | Near-zero false accept rate
Frequently Asked Questions
Why is a 30-second time step the standard for most TOTP implementations?
The 30-second time step represents a carefully chosen balance between security and usability. Shorter intervals like 10 seconds would be more secure because each code is valid for less time, but users would frequently experience codes expiring while they are still typing them, leading to frustration and failed authentication attempts. Longer intervals like 60 seconds keep codes valid longer, increasing the window of vulnerability if a code is intercepted or observed. The 30-second standard gives users enough time to read the code from their authenticator app and enter it into the login form, while keeping the exposure window reasonably short. Some high-security implementations use 60-second windows with 8-digit codes for additional security.
How does the verification window affect TOTP security?
The verification window determines how many time steps before and after the current step the server will accept as valid codes. A window of 1 means the server accepts the current code plus one step before and one step after, effectively creating a 90-second valid window for a 30-second time step. This accommodation handles clock drift between the user device and server. Larger windows increase usability by tolerating more clock skew but reduce security by accepting more codes simultaneously. A window of 1 triples the brute-force odds compared to window 0, from 1 in 1,000,000 to 3 in 1,000,000 for 6-digit codes. Most implementations use window 1 as the default, with some enterprise systems using window 0 and requiring strict NTP synchronization on all devices.
What secret key length should I use for TOTP implementation?
RFC 4226 recommends a minimum secret length of 128 bits (16 bytes), but most modern implementations use 160 bits (20 bytes) as the standard because it matches the HMAC-SHA1 output size. Using 20 bytes provides 160 bits of entropy, making brute-force attacks against the secret computationally infeasible. Some implementations support longer secrets of 32 or 64 bytes for use with HMAC-SHA256 or HMAC-SHA512, though this adds minimal practical security for TOTP purposes since the token space (6 digits) remains the bottleneck. The secret is typically encoded in Base32 format for QR code provisioning, which produces a 32-character string for a 20-byte secret. Never use predictable or short secrets, as the entire security model depends on the secret remaining unknown to attackers.
How vulnerable is TOTP to brute-force attacks?
With standard 6-digit TOTP codes, an attacker has a 1 in 1,000,000 chance of guessing correctly for each attempt within a single time step. With a verification window of 1, this improves to 3 in 1,000,000 (0.0003%). Rate limiting is the primary defense, as most systems lock accounts after 3-5 failed attempts. Without rate limiting, an attacker making 3 attempts per 30-second window would need roughly 100,000 windows (about 35 days of continuous attempts) for a 50% chance of success. Eight-digit codes provide 100x more security at 1 in 100,000,000 odds per attempt. The real-world attack surface is more often phishing (tricking users into revealing current codes) or SIM swapping for SMS-based codes rather than brute force against proper TOTP implementations.
How does TOTP compare to other two-factor authentication methods?
TOTP offers strong security advantages over SMS-based codes because it is not vulnerable to SIM swapping, SS7 network attacks, or phone number porting fraud. Compared to push-based authentication like Duo or Microsoft Authenticator push notifications, TOTP is more resistant to prompt bombing attacks where attackers repeatedly send push requests hoping the user accidentally approves one. Hardware security keys like YubiKey using FIDO2/WebAuthn provide stronger phishing resistance because they verify the domain cryptographically, which TOTP cannot do. TOTP advantages include working offline without network connectivity, being supported by many free authenticator apps, and having no per-authentication costs. The main weakness of TOTP is phishing vulnerability, where an attacker in real-time relays the code to the target service.
Can TOTP be used for purposes beyond user authentication?
While TOTP is primarily known for two-factor authentication, the underlying algorithm has broader applications in security and verification systems. Some services use TOTP-like codes for email verification, password reset confirmation, and transaction authorization in banking applications. API authentication systems sometimes use TOTP as a lightweight alternative to OAuth tokens for machine-to-machine communication where simplicity is valued. IoT devices may use TOTP for periodic authentication handshakes when persistent connections are impractical. The algorithm can also be adapted for generating time-limited access codes for physical security systems, temporary WiFi passwords, and guest access provisioning. However, for most of these use cases, there are often more purpose-built solutions that provide better security guarantees than repurposing TOTP.