Why Java’s Random Is Insecure and How SecureRandom Saves Your Data

Random seed same → same sequence

When the seed is fixed, e.g., 0, Java Random produces identical sequences across runs, allowing an attacker who knows the seed to predict all future values.

Random random = new Random(0);
int cnt = 10;
for (int i = 0; i < cnt; i++) {
    System.out.println(random.nextLong());
}

Java Random does not use 0 as default seed; it combines a dynamic seed using seedUniquifier() and System.nanoTime() with XOR to obtain a unique initial seed.

The seedUniquifier() method uses an AtomicLong and a CAS loop to generate a different seed for each thread.

private static final AtomicLong seedUniquifier = new AtomicLong(8682522807148012L);
private static long seedUniquifier() {
    for (;;) {
        long current = seedUniquifier.get();
        long next = current * 181783497276652981L;
        if (seedUniquifier.compareAndSet(current, next))
            return next;
    }
}

Even with this, the 48‑bit state of java.util.Random can be recovered from a few observed outputs; an attacker can brute‑force the seed in far less than 2^48 attempts.

Seed can be guessed

Regardless of the seed generation method, attackers can infer the seed from observed outputs, and in practice can predict the next values within seconds.

Java Random security analysis

Knowing two consecutive outputs of nextLong or nextDouble is enough to predict the rest of the sequence; the same applies to nextInt and nextFloat if the first two values are leaked.

Random generates only 48 bits of randomness, making exhaustive search feasible on modern CPUs.

SecureRandom for safe randomness

Java provides SecureRandom, which generates cryptographically strong random numbers. Compared to Random, SecureRandom can produce up to 128 bits and does not rely on a fixed seed.

SecureRandom can generate 128‑bit values, while Random is limited to 48 bits.

SecureRandom continuously reads entropy from the operating system’s random devices ( /dev/random or /dev/urandom).

On Linux, three SecureRandom strategies are available:

SHA1PRNG

A pseudo‑random generator based on SHA‑1, used as the default on Windows.

NativePRNGBlocking

Initial seed is taken from 20 bytes of /dev/random; each generation XORs the internal SHA‑1 output with fresh data from /dev/random, which may block if entropy is low.

NativePRNGNonBlocking

Uses /dev/urandom for non‑blocking entropy, providing faster but slightly lower‑quality randomness.

In web services, NativePRNGNonBlocking is recommended for stable performance.

Performance comparison

In a single‑threaded benchmark of 1 000 000 iterations, Random completes in about 10 ms, while each SecureRandom variant takes more than ten times longer.

Summary

Random is insecure for high‑security scenarios; knowing two outputs can compromise the whole sequence.

Use SecureRandom for generating passwords, tokens, or redemption codes.

SecureRandom relies on /dev/random and /dev/urandom to keep the seed constantly changing.

For web applications, NativePRNGNonBlocking offers a good balance of security and performance.

Random provides the best raw performance, but SecureRandom variants are roughly ten times slower.