我只是对同事任务进行代码审查,并遇到了以下几行代码(他正在实现基于Spring Security的登录系统).

@Bean
public PasswordEncoder passwordEncoder(){
    return new BCryptPasswordEncoder(ENCODING_STRENGTH, new SecureRandom(SEED_BYTES));
}

使用常量种子初始化此特定SecureRandom是一个好主意吗？我不这么认为,但不能真正解释原因.

解决方法:

见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.

如果您的SEED_BYTES是常数,则可以预测.

BCryptPasswordEncoder仅使用加密强SecureRandom生成盐,见BCrypt#gensalt：

random – an instance of SecureRandom to use

这导致可预测的盐.

盐应该(最好)是唯一的,见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.

如果使用常量种子,则每次重新启动应用程序后都会获得相同的盐序列.这导致了salt collisions.

盐碰撞和可预测的盐会削弱您的安全性,请参阅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.