在密码哈希中包含迭代计数是否安全答案

【问题标题】：Is it safe to include the iteration count in the password hash在密码哈希中包含迭代计数是否安全
【发布时间】：2014-01-23 16:14:54
【问题描述】：

一位同事经过大量研究（包括听取https://crackstation.net/hashing-security.htm 的建议）实施了我们的密码哈希代码

生成的密码哈希包括盐（应该没问题，并且是验证密码所必需的），还包括迭代计数，这对于密钥拉伸来说很高。

很高兴将迭代计数保存在数据库中，因为可以在单元测试中使用较低的计数，并且如果我们更改计数，则仍然可以验证现有保存的密码哈希。但是我想知道包含这个数字是否安全，因为如果知道迭代次数，蛮力攻击会不会更容易？在我看来，这将防止对增量测试的每个迭代计数进行大量额外检查。

【问题讨论】：

【解决方案1】：

可以在生成的哈希中包含迭代计数。

最重要的是，这允许您在未来的硬件变得更快时增加迭代次数。必须能够适应更快的硬件，而不会丢失旧的哈希值。

隐藏这个数字并没有多大帮助。如果不知道，攻击者会假设一个合理的数字，可能会更高一些。他不仅可以将最后一次迭代与哈希值进行比较，还可以将其间的每一步进行比较。在 BCrypt 的成本参数为对数的情况下，这将是大约 3-5 次比较操作（太小不合理），这没什么大不了的。

PHP 的 password_hash() 等知名 API 也将包含 cost 参数。

编辑： 隐藏迭代次数会给散列过程增加一种秘密，攻击者必须猜测这个数字。虽然添加服务器端机密有更好的可能性，但我试图在我的关于 safely storing passwords 的教程中解释这一点（看看关于胡椒和加密哈希值的部分）。

【讨论】：

我不明白：如果您的迭代计数为 1000，是否需要 1000 次尝试才能打破哈希？我看不出你怎么能在 3-5 内做到这一点。
@orbfish - 这取决于您使用 PBKDF2 算法定义实际的迭代次数。在每次 1000 次迭代之后，您都可以比较结果，因此您只计算一次哈希，但比较它 1000 次。当然，仅在 10 次迭代之后进行比较是没有意义的（没有人只会进行 10 次迭代），您只比较 1000 次迭代中合理的一部分。使用 BCrypt，您没有定义实际的迭代次数，您传递了一个成本因子 iterations=2^costfactor，因此只有 16、32、64、128、... 迭代是可能的，并且只有 2^9、2^10、2^11 , 2^12 比较有意义。
谢谢，现在明白了。