I am just doing a code review of a co-workers task and came across the following lines of code (he was implementing a Spring Security based login system).
@Bean
public PasswordEncoder passwordEncoder(){
return new BCryptPasswordEncoder(ENCODING_STRENGTH, new SecureRandom(SEED_BYTES));
}
Is it a good idea to initialize this particular SecureRandom with a constant seed? I don't think so, but can't really explain why.
See SecureRandom:
Additionally, SecureRandom must produce non-deterministic output. Therefore any seed material passed to a SecureRandom object must be unpredictable, and all SecureRandom output sequences must be cryptographically strong, as described in RFC 1750: Randomness Recommendations for Security.
If your SEED_BYTES is a constant, it is predictable.
BCryptPasswordEncoder uses the cryptographically strong SecureRandom only to generate the salt, see BCrypt#gensalt:
random - an instance of SecureRandom to use
That leads to predictable salts.
The salt should be (at best) unique, see A Future-Adaptable Password Scheme:
As proposed by Morris and Thompson [9], however, lookup tables can be thwarted with the second input to F, which they call a salt. If a random salt is chosen whenever users establish new passwords, and if the salt space is large enough to ensure a negligible probability of recurrence, lookup tables offer an adversary no advantage; he may as well compute F at the time of attack. If, on the other hand, the salt space is too small, the output bits of F become useful predicates on passwords, a fact exploited by the QCrack [12] program described in Section 6.
If you use a constant seed, you will get the same sequence of salts after every restart of your application. That leads to salt collisions.
A salt collision and a predictable salt weaken your security, see Seven Ways To Screw Up BCrypt:
#1: Using A Non-Random Salt
[...] If the salt for any two hashes is the same, then the attacker can re-use the computation to attack both at the same time (for brute force style attacks). [...]
#2: Using An Incorrect Random Source for Salt Generation
[...] Additionally, some of the weak random sources suffer from problems known as "seed poisoning" where an attacker can effect future generated randomness.
