TOTP (RFC 6238) Two-Factor Authentication Simulator
Simulate, inspect, and verify RFC 6238 Time-Based One-Time Passwords (TOTP), Base32 keys, and RFC 4226 dynamic truncation in real-time with WebCrypto.
Authenticator Parameters
Live Token Monitor
RFC 6238 VerifiedScan with Google Authenticator, Bitwarden, or Authy to enroll. To generate high-resolution vectors or add brand logos to your onboarding cards, customize this string with our custom QR code generator.
The Cryptographic Anatomy of TOTP: RFC 6238 and RFC 4226 Dynamic Truncation
Time-Based One-Time Password (TOTP), defined in IETF RFC 6238, is an extension of the HMAC-Based One-Time Password (HOTP) algorithm specified in RFC 4226. Instead of incrementing an arbitrary counter per login attempt, TOTP derives its moving counter directly from the current Unix epoch timestamp, creating a self-synchronizing, cryptographically bound ephemeral passcode that automatically cycles across discrete time windows.
1. Epoch Step Discretization
The continuous Unix timestamp is divided into discrete windows of duration X (typically 30 seconds), calculating counter integer T = ⌊(CurrentTime − T0) / X⌋.
2. Keyed HMAC Computation
The counter integer is packed into an 8-byte big-endian binary buffer and hashed against the shared Base32 secret using HMAC-SHA-1, HMAC-SHA-256, or HMAC-SHA-512.
3. RFC 4226 Dynamic Truncation
The final 4 bits of the HMAC digest select an offset index. Four bytes are extracted, masked with 0x7FFFFFFF, and modulo-divided by 10Digits.
Live Cryptographic Execution Trace (RFC 6238 Mathematical Walkthrough)
| Variable | RFC Identifier | Standard Value | Cryptographic Role |
|---|---|---|---|
| Shared Secret Key | K | 160-bit (Base32 encoded) | High-entropy cryptographic seed securely pre-shared between server and authenticator app |
| Time Step Interval | X | 30 seconds | Discretization window determining validity duration and code expiration rate |
| Epoch Offset | T0 | 0 (Unix Epoch 1970-01-01) | Starting baseline Unix time anchor for measuring elapsed discrete step cycles |
| Pseudorandom Hash | HMAC-PRF | HMAC-SHA-1 / SHA-256 | One-way keyed cryptographic digest engine producing uniformly distributed hash octets |
Two-Factor Authentication Architecture Matrix: TOTP vs HOTP vs FIDO2 / WebAuthn
Selecting the appropriate multi-factor authentication protocol requires evaluating real-time phishability, offline availability, physical token requirements, and mobile ecosystem compatibility:
| Protocol | Synchronization Vector | Phishing Resistance | Offline Usability | Implementation Footprint |
|---|---|---|---|---|
| RFC 6238 TOTP | Unix Real-Time Clock (RTC) | Moderate (Vulnerable to AiTM Reverse Proxy) | 100% Offline Capable | Universal, zero-cost mobile authenticator apps |
| RFC 4226 HOTP | Monotonic Sequential Counter | Moderate (Vulnerable to AiTM Reverse Proxy) | Hardware Counter Token | Susceptible to counter desynchronization skips |
| FIDO2 / WebAuthn | Public Key Asymmetric Challenge | Maximum (Origin-Bound Phishing-Proof) | Hardware Key / Passkey | Requires WebAuthn browser primitives and domain pairing |
| SMS / Voice OTP | Cellular Carrier Signaling | Zero (SIM Swap & SS7 Interception) | Requires Cellular Network | Telephony gateway API fees, high vulnerability risk |
Production Engineering Guidelines for Multi-Factor Authentication
Deploying RFC 6238 TOTP into enterprise backend authentication services demands strict server-side validation rules to prevent replay vulnerabilities and timing side channels:
Essential Server Validations
- • Enforce Single-Use Tokens (Anti-Replay): Always record the timestamp step of the last verified token in the database or Redis cache. Reject any subsequent authentication attempts using the same step within the active validity window.
- • Bound Transmission Skew Windows: Restrict validation skew tolerance strictly to ±1 step (±30s). Expanding the window to ±2 or ±3 steps exponentially widens the window for adversary token replay.
- • Execute Constant-Time Comparisons: Use constant-time byte comparisons (e.g.
crypto.timingSafeEqual) when validating the user-provided code against derived candidates to prevent timing side channels.
Operational Pitfalls to Mitigate
- • AiTM Reverse-Proxy Phishing: Understand that TOTP passcodes can be relayed in real time by adversaries running Evilginx or Modlishka frameworks. Supplement high-risk accounts with FIDO2 WebAuthn passkeys.
- • Unencrypted Secret Storage: Never persist plaintext Base32 secret keys in your user database. Encrypt TOTP secrets at rest using AES-256-GCM or an envelope encryption key management service (KMS).
- • Neglecting NTP Synchronization: Ensure all production application servers maintain continuous Network Time Protocol (NTP) clock synchronization to avoid false rejection spikes.
Frequently Asked Questions (FAQ)
How is a TOTP token calculated under RFC 6238?
TOTP calculates an 8-byte big-endian time-step counter T = floor((CurrentUnixTime - T0) / Period). It then calculates an HMAC digest (HMAC-SHA-1, HMAC-SHA-256, or HMAC-SHA-512) over this counter using the shared Base32 secret. The resulting HMAC digest undergoes dynamic truncation to extract a 31-bit integer, which is modulo-divided by 10^Digits to produce a 6- or 8-digit numeric token.
Why is HMAC-SHA-1 still widely used for 2FA instead of SHA-256?
When Google Authenticator popularized mobile TOTP in 2010, RFC 6238 defined SHA-1 as the primary reference requirement. Because HMAC security relies on the pseudorandom property of the PRF rather than collision resistance, HMAC-SHA-1 remains mathematically resilient against attacks despite SHA-1 collision vulnerabilities.
How does server clock drift affect TOTP validation?
Because client smartphones and enterprise servers may have slightly unsynchronized system clocks, RFC 6238 recommends that authenticators allow a transmission window skew of ±1 step (typically ±30 seconds). The server validates the submitted token against T-1, T, and T+1.
What is Dynamic Truncation (DT) in RFC 4226?
Dynamic Truncation extracts a 4-byte slice from the HMAC hash. The lower 4 bits of the final hash byte define an offset index between 0 and 15. The 4 bytes beginning at that offset are masked with 0x7FFFFFFF to remove the sign bit, creating a positive 31-bit integer.
Does this TOTP simulator send my secret key to an external server?
No. All Base32 conversions, HMAC cryptographic hashing, dynamic truncation, and time-step calculations run entirely within your local browser memory via the native W3C Web Cryptography API (window.crypto.subtle).
What is the standard format of an otpauth:// URI?
The otpauth URI format follows otpauth://totp/Issuer:Account?secret=SECRET&issuer=Issuer&algorithm=SHA1&digits=6&period=30. When scanned as a QR code by an authenticator application, it automatically provisions the shared secret, period, and hash algorithm.
Related & Complementary Utilities
Explore more privacy-first client-side web tools.
Password Entropy Bits & Shannon Information Theory Auditor
Calculate mathematical Hartley combinatorial pool bits, Claude Shannon character information entropy, min-entropy, and NIST SP 800-63B resistance across GPU brute-force threat models.
Diceware Passphrase Multi-Word Cryptographic Generator
Generate cryptographically secure multi-word passphrases using hardware CSPRNG die rolls. Features exact combinatorial pool entropy, Shannon character entropy, NIST SP 800-63B metrics, and brute-force crack time modeling.
Strong Password & Passphrase Generator
Build high-entropy random passwords or memorable multi-word passphrases using cryptographically secure CSPRNG random values with custom character sets.
Password Strength Checker & Cracking Time Analyzer
Zero-Data Exposure: Evaluated 100% locally in your browser. No server calls, no network transmission.