How random are TOTP codes?

Original Article ↗ Hacker News Discussion ↗

Perceived Randomness & Patterns

  • Many commenters report “seeing patterns” in TOTP codes: repeated digits, symmetry, or feeling like the same code reappears.
  • This is generally attributed to human pattern-finding; codes that look special (e.g., 332211, “GABEN”, 6969) are memorable.
  • With only 1,000,000 possible 6‑digit codes, reoccurrences are expected; using the birthday problem, ~1,178 samples give ~50% chance of at least one collision.

Algorithm, Bias & Entropy

  • Standard TOTP/HOTP derive 31 bits from an HMAC-SHA1 output, then take modulo 10^6.
  • Because 2^31 is not divisible by 10^6, low codes (000000–483647) are slightly more likely than high ones.
  • Multiple comments compute both Shannon entropy and min‑entropy and conclude the bias reduces entropy by an utterly negligible amount.
  • Comparisons are drawn to Java’s nextInt(n) (uses rejection sampling to avoid bias) and a biased .NET RNG example.

Determinism vs True Randomness

  • TOTP is deterministic given a secret and timestamp; it is not meant to be random in the sense of unpredictability without the key.
  • Uniform (or nearly uniform) distribution across outputs is desired, plus pseudorandomness so past codes don’t help predict future ones.

“Nice” / “Easy” Codes & UX

  • Ideas floated: generators that only output aesthetically “nice” codes, apps that notify when a “cool” code appears, and tools scoring codes by pattern “easiness.”
  • One project finds roughly half of 6‑digit sequences can be classified as “easy” under chosen pattern rules (adjacent keypad moves, etc.).

Reverse TOTP & Target Codes

  • A “reverse TOTP” toy: instead of current code, compute when a particular code (e.g., 000000, 999999) will occur.
  • With 30‑second steps and 10^6 possibilities, expected wait for a specific code is ~347 days, but actual times can be years due to randomness.

Security of Username + TOTP Only

  • Several commenters argue TOTP alone is weak as a single factor:
    • Each guess has 1-in-10^6 success chance; at scale, spraying codes across many accounts is viable if rate-limits are weak.
    • Mitigation via per-account rate limiting is possible; global limits risk DoS against all users.
  • Others note such schemes may be “good enough” where the goal is lightweight identification, not strong authentication.

OTP via Email/SMS

  • Some systems send one-time codes or login links via email instead of passwords.
  • Users describe this as convenient for support reduction but annoying in practice; some rely on email resets intentionally instead of memorizing passwords.
  • Concern raised that 6‑digit email OTPs alone are not very robust against large-scale brute forcing.

Proprietary Tokens & Clock Drift

  • Distinction made between RFC TOTP and proprietary hardware tokens.
  • One described proprietary system embeds parts of both a click counter and a clock counter into the OTP so the server can track drift over time.

Alternatives: HOTP, Passkeys, Diceware

  • HOTP suggested for memorized future codes, since it’s counter-based rather than time-based.
  • TOTP is seen as being slowly displaced by passkeys/FIDO2 for high-importance accounts, but remains useful as an option.
  • Some dislike platform-tied passkeys for portability and privacy reasons, preferring password managers that store passkeys under user control.
  • Diceware-style multi-word OTPs are proposed by one commenter but others see no input-speed benefit over 6-digit codes.

Statistical Tests & Benford’s Law

  • One question suggests applying a chi-squared test to check distribution; another jokingly dismisses relying on “mere statistics” when histograms are available.
  • Benford’s law is mentioned as an example of non-uniform real-world digit distributions; commenters agree it should not apply to TOTP and would indicate an issue if observed.

Alphanumeric Codes & Key Entropy

  • A user suspects bias in an employer’s alphanumeric OTPs (frequent ‘y’ and ‘z’); with low sample size this remains unproven.
  • Discussion notes that customizing how numbers map to symbols is not “rolling your own crypto” if the underlying number generation is standard.
  • On key length: using 20 characters from [A-Za-z0-9] yields ~120 bits of entropy vs the 160 bits often recommended; commenters consider 120 bits still practically secure.