Use of Insufficiently Random Values - Codepure Documentation

Overview

This vulnerability occurs when an application uses random number generators (RNGs) that produce predictable or easily guessable outputs for security-sensitive purposes. This includes generating session IDs, CSRF tokens, password reset tokens, cryptographic keys, salts, or nonces/IVs. Using weak RNGs (often called pseudo-random number generators or PRNGs) means an attacker might be able to predict future “random” values, compromising security mechanisms. 🎲❓

Business Impact

Predictable random values can lead to various attacks:

Session Hijacking: If session IDs are predictable, attackers can guess valid IDs and take over user sessions.
CSRF Token Bypass: Predictable CSRF tokens can be guessed, nullifying CSRF protection.
Password Reset Poisoning: Predictable password reset tokens allow attackers to reset passwords for arbitrary users.
Cryptographic Weaknesses: Predictable keys, salts, IVs, or nonces weaken encryption and hashing significantly, potentially allowing decryption or cracking.

Reference Details

CWE ID: CWE-330 (Includes CWE-331, CWE-335, CWE-336, CWE-337, CWE-338, CWE-340) OWASP Top 10 (2021): A02:2021 - Cryptographic Failures Severity: High

Framework-Specific Analysis and Remediation

Modern operating systems and language runtimes provide access to cryptographically secure pseudo-random number generators (CSPRNGs). These are designed to produce unpredictable outputs suitable for security purposes. The vulnerability arises when developers use non-cryptographic PRNGs (like Python’s random module, Java’s java.util.Random, or Math.random() in JS/PHP) for generating security-sensitive values. The fix is to always use the system’s CSPRNG for anything security-related.

Framework Context

Using the standard random module for security tokens instead of secrets or os.urandom.

Vulnerable Scenario 1: Predictable Session ID

# custom_session_backend.py
import random
import string

def generate_session_id():
    # DANGEROUS: random.choice uses Mersenne Twister, a non-cryptographic PRNG.
    # Its output can be predicted after observing enough previous outputs.
    length = 32
    chars = string.ascii_letters + string.digits
    return ''.join(random.choice(chars) for _ in range(length))

Vulnerable Scenario 2: Predictable Password Reset Token

# accounts/utils.py
import random
import time

def generate_reset_token():
    # DANGEROUS: Seeding with time makes the output somewhat predictable,
    # especially if the attacker knows roughly when the token was generated.
    # Even without time, `random.randint` is not cryptographically secure.
    random.seed(time.time())
    return str(random.randint(1000000000, 9999999999))

Mitigation and Best Practices

Use the secrets module (Python 3.6+) for generating tokens, keys, etc. For generating random bytes (e.g., salts, IVs), use os.urandom().

Secure Code Example

# custom_session_backend.py (Secure)
import secrets
import string

def generate_session_id():
    # SECURE: secrets.choice uses os.urandom() or equivalent CSPRNG.
    length = 32
    chars = string.ascii_letters + string.digits
    return ''.join(secrets.choice(chars) for _ in range(length))

# accounts/utils.py (Secure)
import secrets

def generate_reset_token():
    # SECURE: Generates a cryptographically strong URL-safe text string.
    return secrets.token_urlsafe(32) # e.g., 32 bytes gives ~43 chars

Testing Strategy

Review code for usage of the random module. Ensure any security-sensitive value generation uses secrets or os.urandom. Static analysis tools can often detect use of weak PRNGs.

Framework Context

Using java.util.Random instead of java.security.SecureRandom.

Vulnerable Scenario 1: Predictable CSRF Token

// filter/CsrfTokenFilter.java
import java.util.Random;
import java.math.BigInteger;

public String generateCsrfToken() {
    // DANGEROUS: java.util.Random uses a linear congruential generator (LCG),
    // which is highly predictable.
    Random random = new Random();
    return new BigInteger(130, random).toString(32); // 130 bits, base32
}

Vulnerable Scenario 2: Predictable IV for Encryption

// service/EncryptionService.java
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import java.util.Random;

public byte[] encryptAesCbc(byte[] keyBytes, byte[] data) throws Exception {
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
    byte[] iv = new byte[16];
    // DANGEROUS: Using the weak Random for a cryptographic IV.
    new Random().nextBytes(iv);
    IvParameterSpec ivSpec = new IvParameterSpec(iv);
    // ... cipher.init(..., ivSpec) ...
}

Mitigation and Best Practices

Always use java.security.SecureRandom for generating salts, IVs, nonces, tokens, and keys.

Secure Code Example

// filter/CsrfTokenFilter.java (Secure)
import java.security.SecureRandom;
import java.math.BigInteger;

public String generateCsrfToken() {
    // SECURE: SecureRandom uses a cryptographically strong source of randomness.
    SecureRandom random = new SecureRandom();
    return new BigInteger(130, random).toString(32);
}

// service/EncryptionService.java (Secure)
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import java.security.SecureRandom;

public byte[] encryptAesCbc(byte[] keyBytes, byte[] data) throws Exception {
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
    byte[] iv = new byte[16];
    // SECURE: Use SecureRandom for cryptographic IVs.
    new SecureRandom().nextBytes(iv);
    IvParameterSpec ivSpec = new IvParameterSpec(iv);
    // ... cipher.init(..., ivSpec) ...
}

Testing Strategy

Review code for instances of new Random(). Replace them with new SecureRandom(). Ensure SecureRandom is used for generating IVs, salts, tokens, etc.

Framework Context

Using System.Random instead of System.Security.Cryptography.RandomNumberGenerator.

Vulnerable Scenario 1: Predictable Verification Code

// Services/OtpService.cs
using System;

public class OtpService
{
    public string GenerateOtp()
    {
        // DANGEROUS: System.Random is not cryptographically secure.
        // Output can be predicted, especially if seeded predictably.
        var random = new Random();
        return random.Next(100000, 999999).ToString("D6");
    }
}

Vulnerable Scenario 2: Predictable Salt Generation

// Services/AuthService.cs
using System;
using System.Security.Cryptography;

public byte[] GenerateSalt()
{
    byte[] salt = new byte[16];
    // DANGEROUS: Using the weak System.Random for a salt.
    var random = new Random();
    random.NextBytes(salt);
    return salt;
}

Mitigation and Best Practices

Use System.Security.Cryptography.RandomNumberGenerator for all security-sensitive random numbers and bytes.

Secure Code Example

// Services/OtpService.cs (Secure)
using System.Security.Cryptography;

public class OtpService
{
    public string GenerateOtp()
    {
        // SECURE: Uses a CSPRNG.
        int otpValue = RandomNumberGenerator.GetInt32(100000, 999999 + 1); // Upper bound is exclusive
        return otpValue.ToString("D6");
    }
}

// Services/AuthService.cs (Secure)
using System.Security.Cryptography;

public byte[] GenerateSalt()
{
    byte[] salt = new byte[16];
    // SECURE: Fills the array with cryptographically strong random bytes.
    RandomNumberGenerator.Fill(salt);
    return salt;
}

Testing Strategy

Review code for usages of new System.Random(). Ensure security-related randomness uses RandomNumberGenerator.Fill() or RandomNumberGenerator.GetInt32().

Framework Context

Using rand(), mt_rand(), or uniqid() for security purposes instead of random_bytes() or random_int().

Vulnerable Scenario 1: Predictable Session ID with `mt_rand()`

// session_handler.php (Custom Session Handler)
function generate_session_id() {
    // DANGEROUS: mt_rand() is a PRNG (Mersenne Twister) and not
    // cryptographically secure. Its state can be predicted.
    return bin2hex(pack('L', mt_rand()) . pack('L', mt_rand()));
}

Vulnerable Scenario 2: Using `uniqid()` for Tokens

Generating a password reset token using uniqid().

// controllers/PasswordController.php
function send_reset_link($email) {
    // DANGEROUS: uniqid() is based on the system time and is easily guessable.
    // Even with more_entropy=true, it's not considered secure enough.
    $token = uniqid('reset_', true);
    // ... save token and send email ...
}

Mitigation and Best Practices

Use random_bytes() to generate cryptographically secure random bytes (for salts, keys, IVs, tokens). Use random_int() to generate cryptographically secure random integers within a range.

Secure Code Example

// session_handler.php (Secure Session ID)
function generate_session_id() {
    // SECURE: random_bytes() uses the OS's CSPRNG.
    return bin2hex(random_bytes(16)); // 16 bytes = 32 hex chars
}

// controllers/PasswordController.php (Secure Token)
function send_reset_link($email) {
    // SECURE: Generate a strong, unpredictable token.
    $token = bin2hex(random_bytes(32)); // 32 bytes = 64 hex chars
    // ... save token and send email ...
}

Testing Strategy

Scan code for usage of rand(), mt_rand(), and uniqid(). Replace their usage in security contexts with random_bytes() or random_int().

Framework Context

Using Math.random() instead of Node’s built-in crypto.randomBytes() or crypto.randomInt().

Vulnerable Scenario 1: Predictable API Key Generation

// utils/apiKeyGenerator.js
function generateApiKey() {
  // DANGEROUS: Math.random() is NOT cryptographically secure.
  // Its output is predictable.
  return Math.random().toString(36).substring(2, 15) +
         Math.random().toString(36).substring(2, 15);
}

Vulnerable Scenario 2: Predictable Salt for Hashing

// utils/auth.js
const crypto = require('crypto');

function hashPasswordWeakSalt(password) {
    // DANGEROUS: Using Math.random() to create a salt.
    const weakSalt = Math.random().toString(16).substring(2);
    const hash = crypto.createHmac('sha256', weakSalt)
                       .update(password)
                       .digest('hex');
    return weakSalt + ':' + hash;
}

Mitigation and Best Practices

Use crypto.randomBytes() to generate secure random bytes. Use crypto.randomInt() for secure random integers.

Secure Code Example

// utils/apiKeyGenerator.js (Secure)
const crypto = require('crypto');

function generateApiKey() {
  // SECURE: Generate 32 cryptographically strong random bytes, encode as hex.
  return crypto.randomBytes(32).toString('hex');
}

// utils/auth.js (Secure Salt)
const crypto = require('crypto');

function hashPasswordSecureSalt(password, callback) {
    // SECURE: Generate a cryptographically strong salt.
    const salt = crypto.randomBytes(16);
    // Use PBKDF2 with the secure salt and high iterations
    crypto.pbkdf2(password, salt, 100000, 64, 'sha512', (err, derivedKey) => {
        if (err) throw err;
        callback(salt.toString('hex') + ':' + derivedKey.toString('hex'));
    });
}

Testing Strategy

Review code for any usage of Math.random(). Replace it with crypto.randomBytes() or crypto.randomInt() in all security-sensitive contexts (token generation, key generation, IVs, salts).

Framework Context

Using Ruby’s default rand() or Random.new instead of SecureRandom.

Vulnerable Scenario 1: Predictable Session ID

A custom session store using rand().

# lib/custom_session_store.rb
class CustomSessionStore
  def generate_sid
    # DANGEROUS: Kernel#rand uses a predictable PRNG (Mersenne Twister).
    rand(36**32).to_s(36) # Example generation
  end
end

Vulnerable Scenario 2: Predictable Nonce for Encryption

Generating a nonce for AES-GCM using rand().

# lib/encryption.rb
require 'openssl'

def encrypt_aes_gcm_weak_nonce(key, data)
  cipher = OpenSSL::Cipher.new('aes-256-gcm')
  cipher.encrypt
  cipher.key = key
  # DANGEROUS: Using weak rand() for a cryptographic nonce.
  iv = rand(2**96).to_s(16).rjust(24, '0') # 96-bit nonce example
  cipher.iv = [iv].pack('H*') # Convert hex string to bytes
  # ... encryption ...
end

Mitigation and Best Practices

Use SecureRandom for all security needs. SecureRandom.hex(n) for hex tokens, SecureRandom.urlsafe_base64(n) for URL-safe tokens, SecureRandom.random_bytes(n) for raw bytes.

Secure Code Example

# lib/custom_session_store.rb (Secure)
require 'securerandom'

class CustomSessionStore
  def generate_sid
    # SECURE: SecureRandom uses the OS's CSPRNG.
    SecureRandom.hex(16) # 16 bytes = 32 hex chars
  end
end

# lib/encryption.rb (Secure Nonce)
require 'openssl'
require 'securerandom'

def encrypt_aes_gcm_secure_nonce(key, data)
  cipher = OpenSSL::Cipher.new('aes-256-gcm')
  cipher.encrypt
  cipher.key = key
  # SECURE: Use SecureRandom for the nonce/IV.
  # `cipher.random_iv` is the preferred way as it uses SecureRandom internally.
  iv = cipher.random_iv
  # Or SecureRandom.random_bytes(12) for GCM
  cipher.auth_data = ""
  # ... encryption ...
end

Testing Strategy

Scan code for usage of rand() and Random.new(). Ensure all security-sensitive random value generation uses methods from the SecureRandom module.

Getting Started

Product Guides

Integrations

Supported Languages

Vulnerability Reference

Security & Trust

User Management

Documentation Index

​Overview

​Business Impact

Reference Details

​Framework-Specific Analysis and Remediation

​Framework Context

​Vulnerable Scenario 1: Predictable Session ID

​Vulnerable Scenario 2: Predictable Password Reset Token

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: Predictable CSRF Token

​Vulnerable Scenario 2: Predictable IV for Encryption

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: Predictable Verification Code

​Vulnerable Scenario 2: Predictable Salt Generation

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: Predictable Session ID with mt_rand()

​Vulnerable Scenario 2: Using uniqid() for Tokens

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: Predictable API Key Generation

​Vulnerable Scenario 2: Predictable Salt for Hashing

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: Predictable Session ID

​Vulnerable Scenario 2: Predictable Nonce for Encryption

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

Overview

Business Impact

Framework-Specific Analysis and Remediation

Framework Context

Vulnerable Scenario 1: Predictable Session ID

Vulnerable Scenario 2: Predictable Password Reset Token

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: Predictable CSRF Token

Vulnerable Scenario 2: Predictable IV for Encryption

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: Predictable Verification Code

Vulnerable Scenario 2: Predictable Salt Generation

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: Predictable Session ID with `mt_rand()`

Vulnerable Scenario 2: Using `uniqid()` for Tokens

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: Predictable API Key Generation

Vulnerable Scenario 2: Predictable Salt for Hashing

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: Predictable Session ID

Vulnerable Scenario 2: Predictable Nonce for Encryption

Mitigation and Best Practices

Secure Code Example

Testing Strategy