Featured Developer Sponsor • Zero-Token Protection
RFC 6238 Standard
Web Crypto HMAC-SHA1/256/512
Browser Simulation
TOTP 2-Factor Authenticator Code Studio & RFC 6238 Simulator
Generate authentic Two-Factor Authentication (2FA) codes in real time from Base32 secret keys. Simulates Google Authenticator, Microsoft Authenticator, Authy, and Bitwarden with live countdown visualization and multi-window drift verification.
Current Active 2FA Token
--- ---
30s
Previous Window (-30s): -
Next Window (+30s): -
0
Unix Epoch (s)
0
Time Step Counter (T)
80 bits
Secret Key Entropy
< 1 ms
HMAC Execution
RFC 6238 Algorithm Specification & Mathematical Derivation
Time-based One-Time Password (TOTP) is an extension of the HMAC-based One-Time Password algorithm (HOTP, RFC 4226). Instead of an incrementing event counter, TOTP uses the current Unix timestamp as the moving factor:
Step 1: Calculate the Time Counter (T):
T = floor((UnixTime - T0) / X)
Where:
- UnixTime is current seconds since January 1, 1970 UTC
- T0 is epoch reference (default: 0)
- X is time step interval (default: 30 seconds)
Step 2: Compute HMAC Value (HS):
HS = HMAC-SHA-1(Key = Base32Decode(Secret), Data = INT_64_BE(T))
Result is a 20-byte (160-bit) binary hash.
Step 3: Dynamic Truncation (DT):
Offset = HS[19] & 0x0F (Extract lowest 4 bits of the last byte; value between 0 and 15)
BinaryCode = ((HS[Offset] & 0x7F) << 24) |
((HS[Offset + 1] & 0xFF) << 16) |
((HS[Offset + 2] & 0xFF) << 8) |
(HS[Offset + 3] & 0xFF)
Step 4: Format Decimal Code:
TOTP = BinaryCode mod 10^Digits (padded to 6 or 8 digits with leading zeros)
5 Fatal Traps in Two-Factor Authentication & TOTP Implementations
Trap 1: Clock Drift & Missing Verification Window Tolerance (RFC 6238 Drift)
Network latency and device clock drift (even by 15–20 seconds) cause client and server time steps to fall out of phase. RFC 6238 Section 5.2 explicitly recommends that authentication servers check at least one preceding and one following time step (a window of (T-1, T, T+1), covering 90 seconds total). Strictly checking only the exact current timestamp causes frequent false rejection of legitimate logins.
Trap 2: Insecure Secret Key Storage & Plaintext Database Leakage
Storing Base32 shared secrets in plaintext within your SQL database completely neutralizes 2FA. If an attacker dumps your database via SQL injection, they acquire every user's master TOTP seed and can generate identical tokens indefinitely. Shared secrets must be encrypted at rest using an envelope key (e.g. AES-256-GCM via AWS KMS or HashiCorp Vault).
Trap 3: SMS/Email 2FA Fallacy (SIM Swapping vs Cryptographic TOTP)
Relying on SMS or email verification codes is vastly inferior to app-based TOTP. SMS messages traverse cellular carrier networks in plaintext and are routinely hijacked via SIM-swapping attacks (bribing or tricking telecom support reps) and SS7 signaling exploits. Offline TOTP authenticators generate codes locally with zero telecom dependency.
Trap 4: Failure to Invalidate Used One-Time Passwords (Replay Attacks)
Under RFC 6238 Section 5.2, an OTP must NEVER be accepted more than once. If a user enters code "123456" at second 5 of a 30-second window, an attacker eavesdropping on the network connection can replay that exact code during the remaining 25 seconds unless the authentication backend records and invalidates the token in a Redis cache.
Trap 5: QR Code Phishing & Reverse Proxy MITM Attacks (Evilginx Bypass)
While TOTP protects against static password credential stuffing, it does NOT protect against real-time Man-in-the-Middle reverse proxies (like Evilginx). If an adversary tricks a user into entering their username, password, and active 6-digit TOTP code onto a spoofed phishing page, the proxy immediately replays the code to the real service and intercepts the authenticated session cookie. Only FIDO2/WebAuthn hardware keys provide cryptographic origin binding against MITM.
Frequently Asked Questions
How does RFC 6238 Time-based One-Time Password (TOTP) work?
TOTP calculates a 6-digit or 8-digit code by applying an HMAC hash (typically HMAC-SHA1) to a shared secret key and the current Unix epoch time divided into 30-second time-steps. The resulting 160-bit HMAC is dynamically truncated to a 31-bit integer and formatted as a decimal code modulo 10^6.
Is my 2FA secret key safe when entered into this tool?
Yes! The entire TOTP computation occurs 100% locally inside your browser using the native Web Cryptography API (window.crypto.subtle). Your secret key is never transmitted across the network or logged in any backend database.
What is the standard time-step interval for TOTP?
The overwhelming majority of modern two-factor authenticators (Google Authenticator, Microsoft Authenticator, Authy, Bitwarden, 1Password) use a standard 30-second time-step interval and 6-digit codes.
What causes TOTP "Invalid Code" errors during login?
The single most common cause is clock drift. Because TOTP relies on the current Unix timestamp, if your device clock is desynchronized by more than 30 seconds from the authentication server, the generated code will belong to a past or future time window and will be rejected.
Can I generate a new random Base32 secret key with this tool?
Yes. You can click the "⚡ Gen Random Secret" button to create a cryptographically secure 16-character (80-bit) or 32-character (160-bit) Base32 secret key compliant with RFC 4648 standards.
Sponsored Utility
While You're Here
Sponsored Recommendations
Advertisement