2021年最优密码存储方案是什么？现有加盐bcrypt方案是否已不安全？

问题1：对方关于原有方案不安全的说法是否属实？ #

该说法存在核心逻辑错误，对密码学基础概念的理解存在明显偏差，结论不成立：

• 盐的设计目标从来就不是需要保密的敏感值，它的核心作用是避免彩虹表批量攻击，保证相同密码的不同用户生成的哈希值完全不同。哪怕盐和哈希一起泄露，这个核心作用依然存在，所谓「盐已经失去原有作用」的说法完全不成立。
• bcrypt是经过全球密码学界数十年验证的慢哈希算法，只要成本因子调整到合理范围（2021年行业标准不低于12，单次计算耗时≥100ms），哪怕攻击者拿到盐，每秒最多只能计算数十次哈希，要跑完7亿级的密码字典破解单个用户密码，都需要数年时间，不存在快速破解的可能。
• 你原有方案中唯一多余的操作是对bcrypt结果额外做SHA3_512存储，bcrypt的输出本身已经内置了盐、成本因子和最终哈希值，不需要额外处理，额外的哈希操作反而可能引入不必要的风险。

问题2：是否应该采用该自定义多盐加密方案？ #

绝对不要采用这个自定义加密方案，这是典型的「自制加密逻辑谬误」，安全行业的铁则是永远不要自己发明未经过公开审计的加密组合，这个方案反而会大幅降低安全性：

• 方案中引入了已经被证实存在碰撞风险的SHA1、CRC32算法，直接将弱校验算法加入加密链路，会引入大量未知的安全漏洞。
• 自定义的多哈希拼接逻辑没有经过任何密码学审计，很容易出现不同输入得到相同中间结果的碰撞问题，反而会降低破解难度。
• 所谓「静态密钥+数据库盐」的思路本身是合理的，对应密码学界早已成熟的「胡椒（Pepper）」方案，有标准实现方式：直接用HMAC算法以静态密钥为key处理明文密码，再传入bcrypt即可，完全不需要自己拼接多种哈希算法。
• 所谓「主流破解工具不支持自定义逻辑所以更安全」的说法完全站不住脚，只要攻击者拿到你的服务端代码，把你的加密逻辑移植到破解脚本只需要几分钟，根本不会提升多少攻击成本，反而你自制逻辑出漏洞的概率是标准算法的上百倍。

2021年最优密码存储方案调整建议 #

你原来的方案只需要做少量调整就足够满足安全要求：

• 保留SSL传输、bcrypt慢哈希、密码强度校验的逻辑
• 确认bcrypt的成本因子≥12，服务器性能够的话可以调到13~14
• 去掉额外的SHA3_512处理步骤，直接存储bcrypt的原生输出
• 如果确实需要加静态密钥增强安全性，采用标准实现：bcrypt(hmac_sha256(用户明文密码, 服务端静态胡椒))即可，不需要额外的用户专属动态盐，bcrypt已经内置生成唯一随机盐的功能。

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