Use of Insufficiently Random Values

A value meant to be unpredictable - a token, an identifier, a nonce - is generated with insufficient entropy, making it guessable or predictable within a feasible attack window even if a nominally-appropriate generator was used. This is a broader category than the PRNG-specific one above; it covers cases where the output is predictable regardless of the exact mechanism, including short numeric codes, sequential identifiers dressed up to look random, or timestamp-derived values.

Predictability is a statistical property that requires collecting and analyzing a meaningful sample of generated values - a single observed value looks the same whether it's genuinely random or subtly predictable.

Statistical analysis of a collected sample of the value in question (session tokens, reset codes, identifiers), checking for patterns, insufficient character-space, or correlation with observable inputs like time.

Tip: This is almost always found through code or configuration review of the actual storage and hashing implementation, rather than through any external test — the stored value looks the same from outside regardless of whether it's properly hashed, so the only reliable check is reading the code that produces it.

Real-World Impact

How passwords are stored determines the entire blast radius of a future database breach. Plaintext storage or a recoverable ("encrypted, not hashed") format means a single database compromise hands over every user's actual password immediately, with no cracking effort required at all. Weak hashing, a fast general-purpose hash without a per-user salt, or an outdated algorithm, means the same breach still requires attacker effort, but often not very much: modern GPU-based cracking makes short work of unsalted or fast-hashed password databases at scale.

Because of widespread password reuse across services, the damage from a poorly-stored password database extends well beyond the breached application itself — leaked credentials get tested ("credential stuffed") against banking, email, and other higher-value targets, which is why this class is treated as high-severity even when the breached application itself holds low-value data.

Insufficiently random values in adjacent systems, password-reset tokens, session identifiers generated with a weak or predictable source, compound the same underlying risk: even a properly-hashed password becomes irrelevant if the reset flow around it can be predicted instead.

Prevention and Secure Design

Preventing Use of Insufficiently Random Values takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Hash with a modern, purpose-built algorithm. Use bcrypt, scrypt, or Argon2 with a per-user salt — never plaintext, never reversible encryption, and never an unsalted or fast general-purpose hash like unsalted SHA-256/MD5.

Never store recoverable passwords, even for legitimate-sounding reasons. A "recoverable" format exists so support can retrieve a forgotten password directly — the correct flow is always a reset, not a retrieval, and that distinction alone prevents this class.

Use a cryptographically secure random source for anything security-relevant. Password-reset tokens, session identifiers, and similar values need to come from a CSPRNG, not a general-purpose or predictable random function.

Rate-limit and expire reset tokens tightly. Even a well-generated reset token should have a short expiry and single-use enforcement, so a leaked or predicted token has a narrow window of usefulness.

Plan for algorithm migration. Hashing recommendations shift over time (work-factor increases, algorithm deprecation) — build the storage schema to support re-hashing on next login rather than assuming today's choice is permanent.