Insecure Randomness
detect, understand, remediate

What is insecure randomness?

Insecure randomness (CWE-330 Use of Insufficiently Random Values, with subclasses CWE-331 Insufficient Entropy and CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator) is the use of a non-cryptographic random number generator to produce a value that the application treats as unguessable. Session identifiers, password reset tokens, OAuth state parameters, CSRF tokens, password salts, encryption initialisation vectors, API keys, MFA backup codes, and one-time passwords all need to come from a source an attacker cannot reproduce. When the source is Math.random in JavaScript, java.util.Random in Java, rand() or mt_rand() in PHP, srand+rand in C, or System.Random in older .NET, the source is reproducible. The token looks random; it is not.

The classification sits inside OWASP A02:2021 Cryptographic Failures, next to but distinct from weak cryptography, which covers algorithm and mode choice, and TLS/SSL misconfiguration, which covers transport-layer choices. Insecure randomness is about the source of the bytes the application feeds into those algorithms. A correct AES-GCM call with a Math.random nonce is still broken; the cipher is sound, the nonce is not. A bcrypt password hash with a salt from java.util.Random is still broken; the hash function is sound, the salt is predictable across registrations and lets an attacker precompute rainbow tables for the entire user base.

On a real engagement the finding rarely ships alone. Predictable session ids hand an attacker the next valid session without credentials, which is broken authentication. Predictable password reset tokens hand the attacker an account, which is password reset territory at the protocol layer and account takeover at the business layer. Predictable JWT signing keys generated from a non-CSPRNG turn the entire token issuance into a forgery surface, which is JWT territory. The bug class sits upstream of all of these.

How insecure randomness fails in practice

The shapes that show up on real engagements

Each row below maps a non-cryptographic API to the security-sensitive context where it commonly leaks into production. Encountering any of these on a pentest is enough to open a finding before the exploitation work begins.

Why insecure randomness really fails

A pseudo-random number generator (PRNG) is a deterministic algorithm. Given the same seed, it produces the same sequence. The cryptographic question is not whether the output looks random to a casual observer, it is whether an attacker who can see a few outputs can recover enough internal state to predict the next ones. Non-cryptographic PRNGs are designed for speed, statistical uniformity, and simulation use cases. They are not designed to resist state recovery.

A worked example: predictable password reset tokens

A common shape on engagements is a password reset endpoint that generates a token, stores it against the user account, and emails a link with that token to the registered address. The reset handler accepts the token and serves the new-password form. The implementation, in legacy PHP, uses md5(uniqid()) to produce the token. Both the hash function and the entropy source are wrong, but the entropy source is the part that matters here.

// Vulnerable handler (PHP)
function generate_reset_token($user) {
    $token = md5(uniqid('reset_', true));
    save_token($user, $token);
    mail($user->email, 'Reset your password', "https://app.example/reset?t=$token");
}

// uniqid() is documented as "based on the current time in microseconds".
// The format is a 14-character hex prefix derived directly from microtime().
// The "more entropy" flag adds a 10-char LCG suffix that does not save it.
// An attacker who can request a reset and observe the issuance time within
// a few seconds can enumerate every microtime() in that window, regenerate
// every uniqid(), hash each one, and arrive at the issued token offline.

The pentester triggers a reset for the target account. They request a reset for their own attacker-controlled account at the same time, capture the token in their inbox, and learn the microtime at issuance to within a few microseconds. They enumerate every microtime in a one-second window around the target reset, generate every uniqid output, take md5 of each, and stop when they hit the token they captured. The same enumeration applied to the target account returns a token that the server accepts. The reset URL works on the first try. No credential phishing, no email server compromise, no session theft; the token itself was guessable.

The fix is structural: switch to random_bytes(32) (or its language equivalent), serialise as base64url or hex, store a hash of the token rather than the token itself, and bind the token to a single-use validity window. On a SecPortal engagement, the proof of impact is the captured reset email plus the offline-generated token plus the timestamped server log entry showing the reset accepted on the first attempt. CVSS 3.1 is calibrated to the highest-privilege account the predictable token reaches; for a self-service reset on a regular user this typically lands at AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N (around 8.1), and rises if the predictable flow targets administrative accounts. The finding stays attached to the engagement record with the token enumeration script, the request, the email, and the log line through retest.

How to detect insecure randomness

How to fix insecure randomness

Reporting an insecure-randomness finding

Insecure-randomness findings get disputed in two predictable ways. Engineering pushes back that the token is "already long enough to be unguessable", missing that length without entropy is decoration, or that the function name has random in it so the function must be random. The strongest reports name the exact call site (file, line, function), the RNG family in use, the operation it supports (session id, password reset, OAuth state, salt, IV, MFA backup code), and the realistic attack model that follows: state recovery for MT, time enumeration for srand, V8 solving for Math.random, or LCG inversion for legacy rand.

On a SecPortal engagement, the finding sits on the engagement record with the affected endpoint and call site, the captured token sample, the entropy analysis output, the proof-of-concept script that recovers the state and predicts the next token, the CVSS 3.1 vector calibrated to the data the predicted token unlocks, the CWE-330 mapping (and CWE-338 where the source is specifically a non-CSPRNG), and the remediation guidance from this page. Pentest engagement records keep the finding linked to the original commit and the retest verification, so the close-out conversation references the actual RNG migration rather than a vague "tokens are random now" ticket. The finding triage workflow covers how to separate scanner-derived flags (a Math.random import in source) from manually validated findings (a captured next-token prediction), so the report differentiates rule hits from confirmed exploits, and the pentest report writing guide covers how to phrase the business impact for a reader who needs to understand why a function called random is not random in the cryptographic sense.

Compliance impact

A pentester checklist for insecure randomness

The list below is the minimum coverage a tester should walk before declaring a target's token surface acceptable. Each item maps to a specific finding shape, with a CVSS profile that reflects the data the predicted value unlocks.