auditing-randomness-and-nonce-quality

Auditing randomness and nonce quality: when the secret is guessable by construction

A whole class of secrets is broken not by a flaw in the algorithm around them but by where their bytes came from. A password-reset token from a statistical generator can be reconstructed from a few prior outputs. A generator seeded from the clock produces the same token twice. A nonce reused across two messages under one key can collapse a mode's confidentiality or leak its authentication key. A token that is unpredictable but only thirty-two bits long is brute-forceable anyway. In every case the cipher, mode, and hash can be perfectly chosen; the value is guessable because of the randomness, the seed, the nonce lifecycle, or the length. You find these by tracing each security-sensitive value back to the generator that produced it and asking whether an attacker can predict or repeat it.

When to use

• A generated value is the only thing standing between an attacker and an account, a message, or a request.
• Tokens, links, codes, session identifiers, nonces, or initialization vectors are produced somewhere in the code.
• You want to separate a value that is unpredictable by construction from one that only looks random.

Scope check

Assess randomness only in code you own or are authorized to review, and reproduce predictability only against test data. Demonstrating that a real token is guessable can expose live accounts, so treat a confirmed finding as sensitive and coordinate. If you can't name the authorization, stop.

The loop

1. Map security-sensitive values to their generator. Inventory the values whose security property is unpredictability: session and authentication tokens, password-reset and email-verification links, cross-site-request tokens, one-time and device codes, API keys, and cryptographic nonces, salts, and initialization vectors. For each, trace back to the call that produced its bytes. The trace, not the variable name, tells you what the value actually is.