bcrypt中saltRounds参数是否可提升密码加密安全性？

不是，saltRounds只是bcrypt哈希安全配置中的核心参数之一，没法单靠它拉满密码存储的安全性。

你看到的示例代码写法本身是bcrypt的标准调用方式：saltRounds是bcrypt的成本因子，控制密钥扩展算法的迭代次数，数值每提升1，哈希计算的耗时就会翻倍，确实是直接决定暴力破解成本的核心配置——数值越高，攻击者拿到哈希后跑字典猜密码的时间成本就越高。目前常规业务场景下，把这个值设为12是比较通用的基线，你可以自己在部署环境压测下，保证单次哈希计算耗时在200ms~500ms区间就行，平衡安全和用户登录体验：别盲目拉到特别高，不然不仅用户登录卡，还可能被恶意请求拖垮服务端CPU；也别低于10，不然当前消费级显卡跑暴力破解的速度会快到没什么防护效果。

想要真正保证密码存储安全，除了合理设置saltRounds，还要注意以下几个环节：

• 必须配合基础的密码强度规则
  要是你不做任何密码校验，允许用户设123456、password这种顶级弱密码，哪怕你把saltRounds拉到15，攻击者拿常见弱密码字典跑照样能快速撞出结果——弱密码本身的熵太低，候选集太小，再高的迭代次数也拉不开破解成本。最少要做基础拦截：要求密码长度不低于8位，混合字母、数字、特殊字符，直接拦截Top1000的常见弱密码。
• 别踩bcrypt本身的使用坑
  要选维护正常的主流bcrypt库，别用停更多年的旧版本，避开已知的算法实现漏洞。bcrypt默认会自动生成16字节的随机salt，和成本因子、哈希结果拼在一起存在最终生成的60位字符串里，不需要你单独存salt，千万别自己传固定的自定义salt，不然等于把salt的防护作用直接废掉；另外要注意原生bcrypt只会处理输入的前72字节内容，超过的部分会被直接截断，如果要支持超长密码，可以先对密码做一次SHA-256哈希再传给bcrypt，避免截断问题。
• 配套的存储、传输逻辑不能漏
  密码从前端传到服务端必须走HTTPS，别明文传输；数据库存bcrypt哈希的字段长度最少要设为60字符，别截断存储的哈希值，也别随便对生成的哈希做自定义加密、转码，避免后续校验失败。
• 安全配置不是一劳永逸的
  硬件算力是逐年上涨的，saltRounds的合理值会随着时间推移慢慢升高，比如10年前行业通用值是10，现在已经逐步升到12，你可以每隔2~3年在当前服务环境下压测调整数值，用户下次登录成功的时候，自动用新的成本因子重新生成哈希覆盖旧值就行，不需要强制用户改密码就能完成强度升级。

内容的提问来源于stack exchange，提问作者Darkpsinight