CWE-331: Insufficient Entropy
Overview
Insufficient entropy occurs when cryptographic operations (key generation, IV/nonce creation, token generation) use weak randomness sources (time, PID, Math.random) instead of cryptographically secure random number generators, making outputs predictable and enabling cryptographic attacks.
OWASP Classification
A04:2025 - Cryptographic Failures
Risk
High: Weak entropy enables prediction of encryption keys, session tokens, CSRF tokens, password reset tokens, API keys, IVs/nonces, and random salts. Attackers can brute-force small entropy spaces, predict sequences, or reproduce random values.
Remediation Steps
Core principle: Ensure sufficient entropy for secrets (tokens/keys/nonces); use OS CSPRNG and correct seeding.
Locate the insufficient entropy source in your code
- Review the flaw details to identify the specific file, line number, and code pattern using weak randomness
- Identify weak entropy sources: Math.random(), rand(), Random() with time() seed, timestamp-based values
- Determine what the random values are used for: encryption keys, IVs/nonces, session tokens, CSRF tokens, password reset tokens, API keys
- Trace the data flow to understand how weak randomness affects security
Use cryptographically secure RNG (Primary Defense)
- Proper Sources: Use OS-provided cryptographic RNGs
- /dev/urandom (Linux)
- CryptGenRandom (Windows)
- SecureRandom (Java)
- secrets module (Python 3.6+)
- crypto.randomBytes (Node.js)
- RNGCryptoServiceProvider (C#)
- NEVER Use: Weak or predictable sources
- Math.random() (JavaScript)
- rand(), random() (C/C++)
- Random() (Python)
- new Random() (Java)
- time() as seed
Generate sufficient entropy
- Session tokens: 128+ bits (16+ bytes) minimum
- Encryption keys: Match key size (256 bits for AES-256, 128 bits for AES-128)
- CSRF tokens: 128+ bits minimum
- Password reset tokens: 256+ bits for high-security operations
- API keys: 256+ bits minimum
Don't seed with predictable values
- Never seed with time(), PID, or counter: These are predictable and reduce entropy
- Use OS-provided entropy sources: Let the OS provide secure random seed from hardware/system entropy
- Don't implement your own PRNG: Use vetted cryptographic libraries
- Trust system cryptographic RNG: SecureRandom, secrets, crypto.randomBytes handle seeding automatically
Validate entropy in testing
- Test token randomness distribution: Verify tokens are uniformly distributed, no patterns
- Check for predictable patterns: No sequential values, repeating bytes, or correlation between tokens
- Verify sufficient length: Ensure tokens meet minimum bit length requirements
- Use entropy analysis tools: Statistical tests (chi-square, runs test) to verify randomness quality
Test the entropy fix thoroughly
- Verify weak entropy sources are no longer used (grep for Math.random, rand(), Random() in security contexts)
- Test token generation produces unique, unpredictable values (generate 10,000 tokens, verify no duplicates or patterns)
- Verify sufficient length for all security tokens (check byte length matches requirements)
- Statistical testing: chi-square test, autocorrelation test to verify randomness quality
- Re-scan with security scanner to confirm the issue is resolved
Common Vulnerable Patterns
- Math.random() for tokens
- rand() seeded with time()
- Using timestamp as IV
- new Random() for cryptographic keys
- Insufficient token length (<128 bits)
Language-Specific Guidance
For detailed, language-specific examples and secure random number generation patterns:
- Python (secrets, os.urandom): See python/INDEX.md - secrets module for cryptographic randomness
- Java (SecureRandom): See java/INDEX.md - SecureRandom for secure entropy
- JavaScript/Node.js (crypto.randomBytes, crypto.getRandomValues): See javascript/INDEX.md - crypto module for random generation
- C# (RandomNumberGenerator, RNGCryptoServiceProvider): See csharp/INDEX.md - .NET crypto providers
- PHP (random_bytes, random_int): See php/INDEX.md - PHP secure random functions