对已经“浓”的盐进行腌制的任何价值。密码？
将密码加盐以获得强大的、唯一的（用户未用于其他应用程序的）密码有什么好处吗？
加盐（据我所知）可以防止使用字典或常见密码生成的彩虹表。它还可以防止攻击者注意到在另一个应用程序中具有相同哈希值的用户。
鉴于强密码（可能）不会出现在生成的彩虹表上，并且聪明的用户将为他想要保护的每个应用程序使用唯一的密码，加盐是否可以保护已经“聪明”的用户？
这是理论上的。我无意停止加盐。
本质上，盐不只是成为密码的一部分吗？它恰好是由网守而不是用户提供的。
Is there any benefit in salting passwords for a strong, unique (not used for other applications by the user) password?
Salting (as I am aware) protects against rainbow tables generated with a dictionary or common passwords. It also protects against an attacker noticing a user with the same hash in another application.
Seeing as a strong password will (likely) not appear on a generated rainbow table, and a smart user will use unique passwords for each application he wants to protect, does salting protect an already "smart" user?
this is theoretical. i have no inclination to stop salting.
in essence, doesn't the salt just become part of the password? it just happens to be supplied by the gatekeeper rather than the user.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您可以保证所有用户永远不会重复使用密码，并且他们的密码都不会采用预先计算冲突哈希值在计算上可行的形式，那么盐确实没有什么额外的好处。
然而，盐的额外成本也很少；然而这些前提确实很难保证，而且如果错误的话，代价也很高。保留盐。
If you can guarantee that all users will never reuse passwords, and that none of their passwords will ever be of a form that it is computationally feasible to precalculate colliding hashes for, then indeed the salt is little additional benefit.
However, the salt is also of little additional cost; while these premises are very hard indeed to guarantee, and the cost of being wrong about them is high. Keep the salt.
除了彩虹表之外，还有暴力破解工具来解析哈希。这不会阻止解析未加盐的哈希值。密码强度越高，所需时间就越长。加盐肯定仍然有意义。
Apart from rainbow tables there are also bruteforce tools to resolve a hash. This doesn't prevent unsalted hashes from being resolved. It only takes a longer as stronger the password is. Salting would certainly still make sense.
这感觉就像您想要做出一个假设，然后将您的安全性建立在该假设之上。当你的假设因某种原因变得糟糕时，你的安全就会变得糟糕。
那么您的假设（强密码不需要加盐）如何变得无效？
1）随着时间的推移，会生成更大、更全面的彩虹表。如果由您的用户选择一个强密码，我会担心这一点。他们可能认为他们做得很好，而您和您的安全检查可能也认为他们做得很好，但后来发现，通过将几个单词和数字串在一起，他们创建密码的思维过程很容易被复制。
2) 如果用户无法选择他们的密码，那么您的强密码生成过程可能会由于错误或其他原因而变得不如您想要的那么强。
3) 您的用户可能懒得想出站点唯一/强密码！这无疑是最重要的问题。您真的想生成一个只有密码专家才能使用的系统吗？ :)
This feels like you want to make an assumption, then base your security on that assumption. When you assumption becomes bad, for whatever reason, then your security becomes bad.
So how might your assumption (that strong passwords don't need salting) become invalid?
1) Over time, larger, more comprehensive rainbow tables are generated. This is something I would worry about if it is up to your user to choose a strong password. They might think they have done a good job, and you and your safety checking might think they have done a good job too, but later it turns out their thought process creating the password was easily duplicated by stringing a few words and numbers together.
2) If users cannot choose their password, your strong password generation process might, due to bug or whatever, turn out to be not as strong as you want.
3) Your user might be too lazy to come up with a site-unique/strong password! This is surely the most important problem. Do you really want to generate a system which is usable only by cryptographic experts? :)
彩虹表绝对不限于字典密码等。大多数倾向于包含每个字符组合，直到达到某个最大长度 - 毕竟，这是一次性的生成成本。您的用户是否都使用 12 个以上字符的密码？不太可能。
Rainbow tables are most definitely not restricted to dictionary passwords or the like. Most tend to include every character combination up to some max length - after all, it's a one time cost for generation. Do your users all use 12+ character passwords? Unlikely.