盐水会提高安全性吗？
我必须哈希密码，因为我使用了bcrypt。 通过遵循教程，我找到了此代码：
const saltRounds = 10;
bcrypt.hash(password, saltRounds).then(hashedPassword => {
//...
}
我搜索了什么是Saltround及其建议，直到我在这里找到 什么是盐回合，如何存储在bcrypt？您可以控制哈希密码所需的时间。
这是否意味着您只需一个属性Saltrounds即可控制隐秘密码的强度？
I had to hash my password, for that i used bcrypt.
By following a tutorial, i found this code :
const saltRounds = 10;
bcrypt.hash(password, saltRounds).then(hashedPassword => {
//...
}
I googled what is saltRound and what's its propos, till i found here
What are Salt Rounds and how are Salts stored in Bcrypt? that you can control the time it takes to hash your passwords.
Does this mean you can control the strength of crypted passwords with just one property saltRounds ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，BCRypt的更多工作确实提高了密码安全性。增加工作因素的全部目的是提供增加。
较高的BCrypt工作因素在上改善了密码安全性，因为单个用户级别，因为很难单独破解每个用户的哈希（如果攻击者只对一个特定帐户感兴趣）。没有哈希 /因素将保护密码极为弱，但是更强大的哈希有更大的机会通过较弱 /中间的密码强度范围扩展保护“向下”保护。
更强大的工作因素还可以在汇总安全级别（对于整个目标用户集）上提高密码安全性。这是因为较高的bcrypt工作因素使攻击在整个集合中都变得更加困难 - 尤其是随着用户数量的增长。需要越多的计算 /内核 /内存，攻击者的昂贵（时间和资源）越昂贵。
当然，权衡的是，攻击者的更多工作（难以破解）也意味着对后卫 /维护者（有效身份验证的较高资源成本）也意味着更多的工作。重要的是要调整您的工作因素，即您和您的用户都可以忍受的最高因素，包括“身份验证风暴”（所有用户都需要同时重新认证）等最坏情况。 BCRYPT的成本为12，目标延迟为0.5秒，通常是这些因素的良好平衡 - 但是您需要评估（和测试！）为自己的用例进行评估。
奖励建议：确保您的图书馆和支持代码可以同时支持 。随着硬件的速度更快，您需要增加新/重置密码的工作因素，同时支持现有密码。幸运的是，大多数库都透明地处理了这一问题 - 但是，再次测试您自己的用例。
Yes, more work for bcrypt does indeed increase password security. The whole purpose of increasing work factors is to provide that increase.
Higher bcrypt work factors improve password security at the individual user level, because it's harder to crack each user's hash individually (if the attacker is interested in just one specific account). No hash / factors will protect an extremely weak password, but stronger hashing has a better chance of extending protection "downward" through a weaker / intermediate range of password strengths.
Stronger work factors also increase password security at the aggregate security level (for the entire target user set). This is because higher bcrypt work factors make attacking the entire set at once materially harder - especially as the number of users grows. The more compute / cores / memory are required, the more expensive (in time and resources) it is for the attacker.
The trade-off, of course, is that more work for the attacker (harder to crack) also means more work for the defender / maintainer (higher resource cost for valid authentications). It's important to tune your work factor to be the highest that both you and your users can tolerate, including worst-case scenarios like an "authentication storm" (where all of your users need to re-authenticate simultaneously). A bcrypt cost of 12, and a target per-user delay of .5 seconds, is often a good balance of these factors - but you need to assess (and test!) this for your own use case.
Bonus advice: make sure that your library and supporting code can support multiple costs simultaneously. As hardware gets faster, you'll want to increase your work factor for new/reset passwords, while simultaneously supporting existing ones. Fortunately, most libraries handle this transparently - but again, test for your own use case.