Articles

CSPRNGs vs. PRNGs: Don't Get Hacked

March 15, 2026 5 min read

A Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) is a bit of a misnomer; it’s not truly random, but it’s "secure" because predicting its output is computationally infeasible.

Here’s a CSPRNG in action, generating a secure session token. Imagine a web server needs to create a unique, unpredictable token for a user’s login session.

import os

# In a real application, this would be part of your web framework's session management
def generate_session_token(user_id):
    # Generate 32 random bytes
    random_bytes = os.urandom(32)
    # Encode them into a URL-safe string
    session_token = base64.urlsafe_b64encode(random_bytes).decode('utf-8')
    print(f"Generated Session Token for User {user_id}: {session_token}")
    return session_token

# Example usage:
user_id = 12345
token = generate_session_token(user_id)

This os.urandom(32) call is the key. It’s not just spitting out numbers based on a simple formula; it’s tapping into the operating system’s entropy pool to get genuinely unpredictable data.

The problem Math.random() (or its equivalent in many languages, like random.random() in Python’s standard library) creates is that it’s a Pseudo-Random Number Generator (PRNG), not a Crypto-graphically Secure PRNG. These PRNGs are designed for speed and statistical randomness (meaning the numbers look random and pass statistical tests), not for unpredictability in a security context. They typically use an algorithm like the Mersenne Twister.

Here’s the fundamental difference:

  • PRNGs (like Math.random()): Start with a "seed" value. The algorithm deterministically generates a sequence of numbers based on that seed. If an attacker knows the seed or can observe enough of the output sequence, they can predict all future (and often past) numbers. This is like a shuffled deck of cards where you can see the entire shuffle pattern.
  • CSPRNGs: Also start with a seed, but it’s much more complex. They use cryptographic primitives (like block ciphers or hash functions) and continuously re-seed themselves from high-entropy sources (like hardware interrupts, disk seek times, network packet timings, or dedicated hardware random number generators). This makes the internal state extremely hard to guess or observe, rendering the output sequence unpredictable even if an attacker sees many previous outputs. This is like a deck of cards that’s not just shuffled but also has cards randomly inserted and removed from the deck constantly.

Why Math.random() Will Get You Hacked

If you use Math.random() for anything security-sensitive, you’re leaving the door wide open for attackers. Think about these scenarios:

  1. Session Tokens: If your session tokens are generated by Math.random(), an attacker observing a few tokens can easily predict the next ones, impersonate users, and take over accounts.

    • Diagnosis: Look for where session IDs, API keys, or authentication tokens are generated. If you see Math.random(), random.random(), or similar non-cryptographic functions, that’s your culprit.
    • Fix: Replace Math.random() with a CSPRNG. On Linux/macOS, use /dev/urandom or os.urandom() in Python. On Windows, use CryptGenRandom. In Node.js, use crypto.randomBytes().
    • Why it works: These sources feed into the OS’s entropy pool, which is constantly mixed with unpredictable environmental noise, making the output impossible to predict.

  2. Password Reset Tokens: Generating a password reset token with Math.random() means an attacker could potentially guess the token and reset any user’s password.

    • Diagnosis: Similar to session tokens, check password reset functionality for predictable token generation.
    • Fix: Use os.urandom(16) (Python), crypto.randomBytes(16) (Node.js), or equivalent CSPRNG functions to generate a sufficiently long and random token.
    • Why it works: The unpredictability ensures only the legitimate user (who receives the token via email) can use it.

  3. Encryption Keys/Nonces: If you’re generating keys or nonces for encryption using a PRNG, the entire encryption scheme can be compromised.

    • Diagnosis: Review your cryptographic implementation. Any generation of keys, initialization vectors (IVs), or nonces using standard PRNGs is a critical vulnerability.
    • Fix: Always use a CSPRNG for cryptographic material. For example, to generate a secure AES key in Python: key = os.urandom(32) for AES-256.
    • Why it works: Cryptographic security relies on the secrecy and unpredictability of keys and nonces; PRNGs fail this requirement.

  4. Two-Factor Authentication (2FA) Codes: If your 2FA codes are generated via a predictable algorithm, an attacker could potentially bypass 2FA.

    • Diagnosis: Examine the mechanism for generating time-based or code-based 2FA tokens.
    • Fix: While TOTP (Time-based One-Time Password) algorithms themselves are standardized, the secret keys used by the server and client for TOTP generation must be securely and randomly generated using a CSPRNG.
    • Why it works: The security of TOTP relies on the shared secret being unknown to attackers.

  5. Salts for Password Hashing: When storing passwords, you must "salt" them with random data before hashing. If you use Math.random() for salts, you’re not adding real randomness, and it makes certain attacks (like rainbow table attacks) easier.

    • Diagnosis: Check how password hashing is implemented. If salts are generated predictably or are static, it’s a problem.
    • Fix: Use os.urandom(16) (Python) or a similar CSPRNG function to generate a unique salt for each password. Store the salt alongside the hashed password.
    • Why it works: A unique, unpredictable salt for each password means an attacker can’t pre-compute hashes for common passwords and must generate hashes individually for each compromised password.

  6. Game Cheating: Even in non-traditional "security" contexts like online games, predictable random numbers can be exploited. If game mechanics (e.g., loot drops, critical hit chances) rely on Math.random(), a clever player might be able to manipulate or predict outcomes.

    • Diagnosis: Look for game logic that depends on random outcomes.
    • Fix: Use a CSPRNG if the outcome needs to be truly unpredictable from the client’s perspective or if it affects game integrity.
    • Why it works: Prevents players from reverse-engineering game logic to guarantee desired random outcomes.

The most common mistake is assuming that "random enough for a simulation" means "random enough for security." Cryptographic security demands a much higher bar: unpredictability.

The next hurdle after implementing CSPRNGs correctly is often understanding how to properly manage the lifecycle and storage of secrets generated by them, such as encryption keys and API tokens.

Want structured learning?

Take the full Cryptography course →