Insecure Randomness

ID

java.insecure_randomness

Severity

high

Resource

Predictability

Language

Java

Tags

CWE:330, CWE:332, CWE:336, CWE:337, CWE:338, NIST.SP.800-53, OWASP:2021:A2, PCI-DSS:6.5.3

Description

Use of cryptographically weak pseudo-random number generator (PRNG).

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are unable to produce true randomness. Pseudo-Random Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is predictable and forms an easy to reproduce numeric stream, unsuitable for use in cases where security depends on generated values being unpredictable.

Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be highly improbable for an attacker to distinguish between it and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Rationale

Randomness is often utilized in software applications for generating keys, tokens, session identifiers, and more. However, not all random number generators are suitable for security-sensitive tasks.

Java’s java.util.Random class, for example, does not provide the unpredictability needed for secure random number generation, as its algorithm and seed value can lead to predictable sequences.

Using java.util.Random in a security context can result in serious vulnerabilities like predictability of keys, which attackers could exploit. Consider the following example:

import java.util.Random;
import org.apache.commons.codec.binary.Hex;

public class TokenGenerator {
    // Insecure: Predictable token generation
    public String generateToken() {
        Random random = new Random();
        byte[] bytes = new byte[16];
        random.nextBytes(bytes);
        return Hex.encodeHexString(bytes);
    }
}

In this example, tokens generated using java.util.Random are vulnerable to prediction, as the randomness source is not sufficiently secure for generating tokens used in security contexts.

Remediation

To remediate the vulnerabilities related to insecure randomness in Java applications, developers should transition to using the java.security.SecureRandom class, which is designed to provide a cryptographically strong random number generator.

import java.security.SecureRandom;
import org.apache.commons.codec.binary.Hex;

public class TokenGenerator {
    // Use SecureRandom with appropriate seed generation
    private final SecureRandom random = SecureRandom.getInstanceStrong();

    public String generateToken() {
        byte[] bytes = new byte[16];
        random.nextBytes(bytes);
        return Hex.encodeHexString(bytes);
    }
}

Below are best practices to ensure appropriate randomness for cryptographic tasks in Java applications :

  1. Use SecureRandom: Replace java.util.Random with java.security.SecureRandom for tasks requiring secure randomness, such as generating cryptographic keys or tokens.

  2. Seed Management: Avoid setting a custom seed for SecureRandom, as it manages seeds internally to ensure strong randomness and entropy. If you must seed, ensure it is done securely and with a truly random value.

  3. Algorithm Specification: While SecureRandom provides reasonable defaults, explicitly specifying a strong algorithm (e.g., SHA1PRNG) can be beneficial if the application demands it and is supported in your environment.

The SecureRandom.getInstanceStrong() method ensures a strong algorithm and seed generation is used, or throws a NoSuchAlgorithmException if the environment does not support it. This failure is a better practice instead of defaulting into weak security.

By adhering to these practices, Java applications can achieve secure randomness necessary for maintaining strong security in sensitive operations.

Configuration

The rule has the following configurable parameters:

  • checkSecurityContext, that indicates if the detector should raise issues that are not located under a security context. When this is set to false, the issues not located under a security context will still be reported but with INFO severity.

  • securityContextPattern, the pattern used to match the code units (like functions) that are related to a security context.

References

  • CWE-338 : Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG).

  • CWE-330 : Use of Insufficiently Random Values

  • CWE-332 : Insufficient Entropy in PRNG

  • CWE-336 : Same Seed in Pseudo-Random Number Generator (PRNG)

  • CWE-337 : Predictable Seed in Pseudo-Random Number Generator (PRNG)

  • OWASP - Top 10 2021 - A2 : Cryptographic Failures

  • CERT MSC63J : Ensure that SecureRandom is properly seeded