我试图说服项目的高层使用迭代强化功能来保护新系统的密码存储。当前的提议将存储类似于加盐 SHA-256 的 HMAC 的东西（可能其他 HMAC 输入被单独存储以提高安全性）。
安全开发人员使用不同的语言，因此基本上不可能直接与他们沟通，或者准确地确定需求。我直接去找那些似乎只了解商业案例研究的高层。在我的抗议中，有人告诉我，基本上说服他们的唯一方法是找到一些真实世界的主要密码泄露示例，这些示例同时使用了盐和 HMAC，但没有使用迭代强化，因此导致许多密码被泄露。
请理解，我不会尝试实现不可能并让他们实施密码存储的确切标准建议。我只是希望他们考虑迭代强化。
是否有任何使用盐和 HMAC 的突出现实示例，但由于缺乏迭代强化，许多密码还是被泄露了？Facebook，LinkedIn等知名公司的奖励积分。
也许指出在没有证据表明数据受损的情况下发生的违规行为也很重要。例如，LastPass 使用了“5,000 轮 PBKDF2-SHA256”和随机盐 ( https://blog.lastpass.com/2015/06/lastpass-security-notice.html/ )。自违规以来，没有迹象表明主密码已被破解。
这并不是说我们一定会知道数据库是否损坏。例如，如果数据库被泄露并驻留在用户的机器上，这并不意味着他会将成功破解的密码发布到 Pastebin。
在发布密码重置之前，通过声明最少的用户帐户将受到损害来引入这个想法将是一个很好的选择。从而降低风险和法律责任。
我不相信您会按照您的要求找到违规/密码破解的示例。256 位 SHA-2 加盐哈希的 HMAC 目前被认为可以满足例如联邦政府的 NIST 标准。[联邦标准要求 HMAC 至少为 112 位，顺便说一句。]
但是，IMO，您的关注对于解决方案的寿命是有好处的。SHA-2 正在逐步淘汰。SHA-3 于 2 个月前由 NIST 正式发布。FIPS202 你同事提倡的方法是上一代的，所以暂时应该没问题，但在正式弃用之前不会有很长的寿命。
顺便说一句，哈希函数的迭代是一种成熟的强度保护方法，但应该注意的是，假设攻击者知道迭代次数，它只提供针对暴力攻击的线性值。同样，任何不加盐的人都应该被赶出软件开发人员的行列，但盐只能防止基于表的攻击。今天，当然还有未来，真正的问题是蛮力。密码长度和复杂性要求是最重要的保护措施，所有敏感访问都必须考虑 2FA。
这不是应该如何处理这种决定。
安全措施是可用性、成本和安全性之间的权衡。为了评估风险缓解技术，您需要评估该选择的所有三个要素：
在您的情况下，使用行业标准的密码派生系统可能对可用性的影响非常小：除非您使用非常严格的设备，否则对用户（所有人）的影响很可能可以忽略不计。
添加密钥扩展步骤本身就提供了两个安全优势：它使通过暴力破解特定密码变得相当困难，如果您使用标准密码推导功能，它还可以让您在非常稳固的基础上假设您使用了所有可能的措施来保护您的用户（在密码泄露的情况下，这在尝试重新获得信任时并不是一个次要因素）。
至于成本，实际上很大程度上取决于您的系统是如何构建的：在操作中添加一个漫长的、强制性的计算阶段很可能会增加您的基础架构成本：您将需要更多的 CPU 周期来处理相同数量的用户身份验证请求. 当然，具体有多少，只有你自己才能弄清楚。
OWASP 有一个很棒的密码存储备忘单。这些指南基本上是大多数信息安全从业者会向他们的客户推荐的内容。请务必查看有关工作因素的部分。
另外，请参阅有关如何安全地散列密码的这篇文章