logo

Use of Insufficiently Random Values

Stable Class
Structure: Simple
Description

This vulnerability occurs when an application uses random values that are not sufficiently unpredictable in security-sensitive operations, making them easier for attackers to guess or calculate.

This vulnerability occurs when an application uses random values that are not sufficiently unpredictable in security-sensitive operations, making them easier for attackers to guess or calculate.
Extended Description

Many security mechanisms rely on the complete unpredictability of random values. This includes generating session tokens, cryptographic keys, password reset tokens, or initialization vectors. If the random values are predictable—due to a weak random number generator, a small range of possible values, or using a seed that is not random—attackers can guess or brute-force these values, bypassing the intended security control. To prevent this, developers should use cryptographically secure random number generators (CSPRNGs) provided by the platform's security libraries, which are designed to produce values that are statistically random and unpredictable. Avoid using standard, non-cryptographic functions like `rand()` for security purposes. Always ensure the random source has sufficient entropy and that the generated values have a large enough range to withstand brute-force attacks.
Common Consequences 3
Scope: ConfidentialityOther

Impact: Other

When a protection mechanism relies on random values to restrict access to a sensitive resource, such as a session ID or a seed for generating a cryptographic key, then the resource being protected could be accessed by guessing the ID or key.

Scope: Access ControlOther

Impact: Bypass Protection MechanismOther

If product relies on unique, unguessable IDs to identify a resource, an attacker might be able to guess an ID for a resource that is owned by another user. The attacker could then read the resource, or pre-create a resource with the same ID to prevent the legitimate program from properly sending the resource to the intended user. For example, a product might maintain session information in a file whose name is based on a username. An attacker could pre-create this file for a victim user, then set the permissions so that the application cannot generate the session for the victim, preventing the victim from using the application.

Scope: Access Control

Impact: Bypass Protection MechanismGain Privileges or Assume Identity

When an authorization or authentication mechanism relies on random values to restrict access to restricted functionality, such as a session ID or a seed for generating a cryptographic key, then an attacker may access the restricted functionality by guessing the ID or key.
Detection Methods 7
Black Box
Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic. Attach the monitor to the process and look for library functions that indicate when randomness is being used. Run the process multiple times to see if the seed changes. Look for accesses of devices or equivalent resources that are commonly used for strong (or weak) randomness, such as /dev/urandom on Linux. Look for library or system calls that access predictable information such as process IDs and system time.
Automated Static Analysis - Binary or BytecodeSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis
Manual Static Analysis - Binary or BytecodeSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Dynamic Analysis with Manual Results InterpretationSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Man-in-the-middle attack tool
Manual Static Analysis - Source CodeHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections)
Automated Static Analysis - Source CodeSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
Architecture or Design ReviewHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Potential Mitigations 5
Phase: Architecture and Design
Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations with adequate length seeds. In general, if a pseudo-random number generator is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a "random enough" number.
Phase: Implementation
Consider a PRNG that re-seeds itself as needed from high quality pseudo-random output sources, such as hardware devices.
Phase: Testing
Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.
Phase: Architecture and DesignRequirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").
Phase: Testing
Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
Demonstrative Examples 2

ID : DX-45

This code attempts to generate a unique random identifier for a user's session.

Code Example:

Bad
PHP
php
Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.
This example also exhibits a Small Seed Space (Small Seed Space in PRNG).

ID : DX-46

The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

Code Example:

Bad
Java
java
This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.
Observed Examples 18
CVE-2021-3692PHP framework uses mt_rand() function (Marsenne Twister) when generating tokens
CVE-2020-7010Cloud application on Kubernetes generates passwords using a weak random number generator based on deployment time.
CVE-2009-3278Crypto product uses rand() library function to generate a recovery key, making it easier to conduct brute force attacks.
CVE-2009-3238Random number generator can repeatedly generate the same value.
CVE-2009-2367Web application generates predictable session IDs, allowing session hijacking.
CVE-2009-2158Password recovery utility generates a relatively small number of random passwords, simplifying brute force attacks.
CVE-2009-0255Cryptographic key created with a seed based on the system time.
CVE-2008-5162Kernel function does not have a good entropy source just after boot.
CVE-2008-4905Blogging software uses a hard-coded salt when calculating a password hash.
CVE-2008-4929Bulletin board application uses insufficiently random names for uploaded files, allowing other users to access private files.
CVE-2008-3612Handheld device uses predictable TCP sequence numbers, allowing spoofing or hijacking of TCP connections.
CVE-2008-2433Web management console generates session IDs based on the login time, making it easier to conduct session hijacking.
CVE-2008-0166SSL library uses a weak random number generator that only generates 65,536 unique keys.
CVE-2008-2108Chain: insufficient precision causes extra zero bits to be assigned, reducing entropy for an API function that generates random numbers.
CVE-2008-2108Chain: insufficient precision (Insufficient Precision or Accuracy of a Real Number) in random-number generator causes some zero bits to be reliably generated, reducing the amount of entropy (Insufficient Entropy)
CVE-2008-2020CAPTCHA implementation does not produce enough different images, allowing bypass using a database of all possible checksums.
CVE-2008-0087DNS client uses predictable DNS transaction IDs, allowing DNS spoofing.
CVE-2008-0141Application generates passwords that are based on the time of day.
References 5
FIPS PUB 140-2: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES
Information Technology Laboratory, National Institute of Standards and Technology
25-05-2001
https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf(2025-05-21)
ID: REF-267
Building Secure Software: How to Avoid Security Problems the Right Way
John Viega and Gary McGraw
Addison-Wesley
2002
ID: REF-207
Writing Secure Code
Michael Howard and David LeBlanc
Microsoft Press
04-12-2002
https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223
ID: REF-7
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation
Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler, and Rama S. Moorthy
07-2014
https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx(2025-09-05)
ID: REF-1479
Likelihood of Exploit

High

Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
Not Technology-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Related Attack Patterns
Functional Areas
  1. Cryptography
  2. Authentication
  3. Session Management
Related Weaknesses
ChildOf: Protection Mechanism Failure (CWE-693)
CanPrecede: Guessable CAPTCHA (CWE-804)
Taxonomy Mapping
  • PLOVER
  • 7 Pernicious Kingdoms
  • OWASP Top Ten 2004
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • WASC
  • WASC
  • The CERT Oracle Secure Coding Standard for Java (2011)
Notes
RelationshipThis can be primary to many other weaknesses such as cryptographic errors, authentication errors, symlink following, information leaks, and others.
MaintenanceAs of CWE 4.3, Use of Insufficiently Random Values and its descendants are being investigated by the CWE crypto team to identify gaps related to randomness and unpredictability, as well as the relationships between randomness and cryptographic primitives. This "subtree analysis" might result in the addition or deprecation of existing entries; the reorganization of relationships in some views, e.g. the research view (Research Concepts); more consistent use of terminology; and/or significant modifications to related entries.
MaintenanceAs of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.