TOTP / 2FA Code Generator

TOTP: How Six Digits Protect Your Account

When you scan a QR code in Google Authenticator (or 1Password, Authy, Bitwarden, etc.) and the app starts producing rotating 6-digit codes, that's TOTP, Time-based One-Time Password, RFC 6238. The math is small (one HMAC and some truncation), and the security story is straightforward: a shared secret you scan once, code generation that requires the secret AND the current time, codes that rotate every 30 seconds so a stolen code is only useful briefly.

This tool computes TOTP codes from any Base32 secret you provide, for testing your own service's TOTP integration, debugging clock drift, or as a fallback authenticator when your phone is unavailable.

The Algorithm

Inputs

• Secret: shared between server and client. Random bytes, ≥128 bits recommended. Encoded as Base32 for QR display.
• Time step: usually 30 seconds.
• Digits: usually 6.
• Algorithm: usually HMAC-SHA1.

Steps

1. Compute time counter:

   Both sides do this. The counter changes once every 30 seconds.

2. Encode T as 8-byte big-endian:

3. HMAC the counter with the secret:

   20-byte output for SHA-1.

4. Dynamic truncation:

   31-bit positive integer.

5. Modulo to digits:

6. Zero-pad to digits:

Example in JavaScript

The whole algorithm is ~30 lines of JavaScript.

Base32, Why Not Base64?

TOTP secrets are encoded in Base32, not Base64. Reasons:

• No case-sensitivity issues: Base32 uses only uppercase letters and digits 2-7. Easier to type without errors. (Base64 a and A are different.)
• No ambiguous characters: skips 0/O, 1/I.
• Manual entry: when users can't scan a QR code, they need to type the secret. Base32 is more typeable.

Base32 alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZ234567. 32 chars = 5 bits each.

Padding with = is optional in TOTP secrets.

The `otpauth://` URI

When you scan a QR code in your authenticator app, it's parsing a otpauth:// URL:

Components:

• totp, type. Also hotp for counter-based.
• Example:alice@example.com, label. Issuer:Account. Displayed in the app.
• secret=..., Base32 secret (required).
• issuer=Example, duplicate of label issuer; required by many apps.
• algorithm=SHA1, SHA1, SHA256, or SHA512.
• digits=6, usually 6, sometimes 8.
• period=30, seconds per code.

Generating the QR code

Most TOTP setup screens generate this URI server-side, encode it as a QR code, and render the QR. User scans → authenticator app parses the URI → secret is stored.

Manual entry

Most authenticators also accept manual entry: type the secret, configure issuer/account, set algorithm/digits/period. Less foolproof but works when QR scanning fails.

Operational Considerations

Clock skew tolerance

If the client and server clocks differ by 30+ seconds, the codes won't match. Standard practice:

• Server accepts ±1 time step. So a 30-second period means codes from the past 30s, current 30s, and next 30s all validate. 90-second total tolerance.
• Sync via NTP on both sides. Most OSes do this automatically.

Rate limiting

A 6-digit code has 10^6 = 1M possible values. Brute-force from a single account takes:

• 10 attempts/second → 100,000s = 28 hours unrestricted.
• With server lockout after 5 failures → effectively unbrute-forceable for a single account.

Implement lockouts. Without rate limiting, TOTP is broken. With it, TOTP is strong enough for most threat models.

Secret storage

The server must store the TOTP secret for every user. Encrypt at rest, if your DB is breached, the attacker shouldn't be able to generate codes. Common pattern: encrypt with a master key in HSM or KMS; decrypt only for verification.

Revocation

When a user loses their authenticator device:

• Backup codes, generate 10 single-use codes at TOTP setup; user prints/saves them.
• Account recovery, typically via email or admin support.
• Don't rely on TOTP alone for critical accounts; pair with hardware keys or passkeys.

Alternatives to TOTP

SMS

Worse than TOTP. SIM-swap attacks, SMS interception, telecom-side vulnerabilities. NIST SP 800-63B (2017+) deprecates SMS for high-assurance authentication.

Push notifications (Duo, Okta Verify)

Better UX than typing codes. Vulnerable to "MFA fatigue" attacks, attacker spams pushes until user approves one by accident. Many providers added number-matching (user types digits shown on the screen) to mitigate.

Hardware tokens (YubiKey, Titan)

FIDO2 / WebAuthn. Public-key crypto, phishing-resistant. Best mainstream option for high-value accounts.

Passkeys

WebAuthn-based, OS-managed (Apple Keychain, Google Password Manager, 1Password). Phishing-resistant, syncs across devices. Increasingly mainstream.

Recommendation hierarchy (2026)

1. Passkeys / WebAuthn for primary auth where supported.
2. Hardware FIDO key (YubiKey) for high-value accounts (admin panels, banking).
3. TOTP as widely-supported 2FA when above unavailable. Still strong with rate limiting.
4. Push with number matching, when service offers it.
5. SMS only when nothing else available; treat as weakest layer.
6. Email for password recovery, not as MFA.

Common Mistakes

Storing secrets in plaintext

Encrypt at rest. KMS / HSM. Don't trust DB encryption alone.

Not rate-limiting verification

6 digits without rate limits = trivial brute force.

Accepting same code twice

After a user logs in with code "123456" at time T, reject the same code if presented again within the time window. Otherwise an attacker who saw the code can replay it within the 30-second window.

No clock skew tolerance

Reject codes that differ from current by exactly one step? Many users will be locked out for clock drift. Allow ±1 step.

Long time periods

Some legacy systems use 60s. Doubles the window of vulnerability for stolen codes. Stick with 30s.

Predictable secrets

secret = "12345678" Base32 = GEZDGNBVGY3TQOJQ is NOT random. Use crypto.getRandomValues(new Uint8Array(20)) for 160 bits, then Base32-encode.

QR code over insecure channel

If the QR code (containing the secret) is displayed on an HTTP page, intercepted, screenshot in untrusted context, the attacker has the secret forever. Use HTTPS, encourage immediate scan, don't email QR codes.

Implementing TOTP

If you're integrating TOTP into your own service:

Setup flow

1. User clicks "Enable 2FA."
2. Server generates random 160-bit secret.
3. Server stores secret encrypted, marked "pending."
4. Server displays QR code with otpauth:// URI.
5. User scans with authenticator app.
6. User types current code to confirm.
7. Server verifies code; if correct, marks secret "active."
8. Server generates backup codes; shows once.

Verification flow

1. User submits code with login.
2. Server fetches user's TOTP secret.
3. Server computes expected code for current time (and ±1 step).
4. Constant-time compare.
5. Track recently-used codes to prevent replay.
6. Rate-limit failures.

Libraries

• Node: otplib, speakeasy.
• Python: pyotp.
• Go: pquerna/otp.
• Rust: totp-rs, totp-lite.

All these implement RFC 4226 / 6238 correctly. Don't roll your own unless you really know what you're doing.

Privacy

The generator runs entirely in your browser: Base32 decode (JS), HMAC-SHA1 (Web Crypto API), truncation arithmetic. Your secret stays in memory; never written to disk, never sent to a server. Open DevTools Network during use: zero outbound requests. This matters specifically here, a TOTP secret is as sensitive as a password for the 2FA layer; if the tool uploaded it, the operator could generate your codes and bypass your 2FA forever. Use this tool to verify a TOTP integration, debug clock drift, or compute codes from a known secret, not as primary 2FA storage (use a password manager or authenticator app for that).