By DeepSource

SecureRandom seeds must not be predictableJAVA-S1031

Security instances must not be initialized with a predictable or constant seed value.

Seeding a SecureRandom instance with a predictable value will render any random values generated by it unusable for cryptographic purposes.

This issue will be raised if a constant or a predictable value (like the system clock) is used as a seed value for a SecureRandom instance.


Bad Practice

SecureRandom notSoRandom = new SecureRandom();
notSoRandom.setSeed(3L); // This is a very predictable seed!

// This uses the SecureRandom(ByteArray seed) constructor:
notSoRandom = new SecureRandom("qwerty".getBytes());


Just allow the SecureRandom instance to initialize itself. Most implementations will properly initialize SecureRandom with suitable random data, ensuring good behavior.

SecureRandom secure = new SecureRandom();

// ...