...
An adversary should not be able to determine the original seed given several samples of random numbers. If that restriction is not ensured, all future random numbers may be successfully predicted by the adversary.
Noncompliant Code Example
This noncompliant code example constructs a secure random number generator that is seeded with the specified seed bytes:
...
This constructor searches a registry of security providers and returns the first provider that supports secure random number generation. If no such provider exists, an implementation-specific default is selected. Furthermore, the default system-provided seed is overridden by a seed provided by the programmer. The current system time used as seed is predictable and can result in the generation of random numbers with insufficient entropy.
Compliant Solution
Prefer the no-argument constructor of SecureRandom that uses the system-specified seed value to generate a 128-byte-long random number:
...
Note that use of the setSeed() method to seed the SecureRandom object prior to invoking nextBytes() is insecure because it bypasses the standard system-generated seeding mechanism. It is also good practice to specify the exact random number generator and provider for better portability.
Applicability
Insufficiently secure random numbers enable attackers to gain specific information about the context in which they are used. For instance, an attacker may be able to guess a cryptographic key.
Insecure random numbers are useful in some contexts that do not require security. These are addressed in the exceptions to MSC02-J. Generate strong random numbers.
Bibliography
...