这看起来像是密码的强盐吗
这看起来像是与密码一起使用的安全盐吗？有什么改进或建议或明显的缺陷吗？
$salt = '';
for ($i = 0; $i < 50; $i++) {
$salt .= chr(rand(33, 126));
}
Does this look like a safe salt to use with a password? Any improvements or suggestions or obvious flaws?
$salt = '';
for ($i = 0; $i < 50; $i++) {
$salt .= chr(rand(33, 126));
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您不需要将盐设置得很长，而且它们的加密安全性并不重要。盐的目的只是让彩虹表攻击变得更加困难，因为密码和哈希值之间不再有一对一的映射。 （它们还可以防止管理员在数据库中看到 482c811da5d5b4bc6d497ffa98491e38，然后知道 Joe 的密码是“password123”。）
即使是 4 字节的 salt 也绰绰有余，因为您现在有 232 任何密码都有 40 亿个潜在的哈希值。
You don't need to make salts really long and it's not important that they be cryptographically secure. The point of salts is simply to make rainbow table attacks harder as you no longer have a 1-to-1 mapping between passwords and hashes. (They also keep administrators with wandering eyes from seeing 482c811da5d5b4bc6d497ffa98491e38 in the database and then knowing Joe's password is "password123".)
Even a 4-byte salt would be more than sufficient as you'd now have 232 ≈ 4 billion potential hashes for any password.
我不认为
rand是一个好的 PRNG。如果我没记错的话，它直接映射到 c PRNG，它在许多实现中具有非常小的（如 32 位）内部状态。而且它的种子也不好。但由于盐最重要的作用是防止预先计算的彩虹表（此代码就是这样做的），因此它应该足够了。
我通常将盐分为两部分：
这样，攻击者只能访问数据库而不能访问配置文件（如果攻击使用 SQL 注入，则可能出现这种情况），那么他仍然无法破解密码。
I don't think
randis a good PRNG. If I recall correctly it maps directly to the c PRNG, which in many implementations has a horribly small(like 32bit) internal state.And it isn't well seeded either. But since the most important role of a salt is preventing pre-calculated rainbow-tables, which this code does, it should be enough.
And I typically split my salt in two parts:
That way an attacker who only gains access to the database but not the config file(a probable scenario if the attack uses SQL injection) then he still can't crack the passwords.
我会使用 mt_rand 因为它更快，但这对于盐来说绝对足够了。
I would use
mt_randsince it is faster, but this is definitely sufficient for salt.盐的安全性主要取决于长度。随机性并不是非常重要，只要它对每个用户来说都是不同的即可。无论如何，您最终都会以纯文本形式存储它，以便您可以在散列过程中使用它。
Length is what mostly makes a salt safe. Randomness isn't super important, as long as it is different for every user. You're going to end up storing it in plain-text anyways so you can use it during hashing.