我是否可以根据系统时间动态计算PBKDF2的适当迭代次数，而不是使用固定值？

Question

您能根据系统时间选择PBKDF2迭代的次数吗？

我听说过一些人建议，PBKDF2的迭代次数应该每两年增加一倍(从2000年PKCS #5发布时推荐的1000个迭代开始)。

至少从理论上讲，您可以根据当前时间通过一个方程确定理想的迭代。也许是这样的：

year = <current time in years>
exponent = (year - 2000) / 2
iterations = 1000 x (2 ^ exponent)

在编写本报告时，它的值大约为115,196次。

假设：

• 系统时钟可以信任。
• 迭代次数与散列一起存储，因此哈希验证仍然是可能的。
• 保护措施已经到位，以防止系统试图使用可笑的迭代次数进行散列。
• 您将继续监视在特定硬件上散列密码所需的实际时间。
• 您定期升级硬件以满足不断增长的性能要求。
• 您可以选择适当的基础哈希算法。

这样的制度是否安全和实用呢？

Answer 1

当然可以--但至于这是一个实际的还是明智的主意，我不这么认为。实现密码系统/协议并假定它们在10年后会很好是不明智的。

密码学是一个迅速变化的动态领域；算法被打破，硬件得到改进，政府试图对该领域进行破坏，并且攻击变得越来越复杂。确保系统安全的唯一方法是随时了解密码/安全领域中发生的事情，并相应地调整系统/协议。例如，尽管建议周期性地加倍PBKDF2循环，但社区中的许多人现在建议使用像氪石这样的硬PBKDF，使PBKDF2或多或少地冗余(尽管并不完全是这样，因为它在氪星内部使用，在内存不可用的系统中使用)。

但是，您的建议确实有一个好处:绝大多数安全/密码协议都会被实现和忘记。例如，看看连网惨败 --在设计系统时，架构师可能(尽管错误地)认为用户密码的sha1散列是足够安全的。如今，一个知名网站这样做的想法是不可想象的(希望如此)。因此，从这个意义上说，你的建议至少是试图保持最新的，而不是静态的系统，总比什么都没有好。不过，我认为持续的审议和更“手拿”的方法是较可取的。

Answer 2

这不是一个好办法。

用于PBKDF2的正确迭代次数是“尽可能多地容忍”。对于给定的硬件，这个数字或多或少是固定的(假设它不是重载的)。您建议的计算类型对于确定是否满足有效的最小迭代次数非常有用。

选择迭代次数的适当方法是对其进行基准测试。许多慢散列库支持这种校准。本质上，您执行名义次数的迭代(例如10,000次)，并计算散列所花费的CPU时间(而不是挂钟时间)。将迭代次数除以实际花费的CPU秒数(例如0.06s)，获得每秒的散列率(在本例中为166,666 to )。现在以秒为单位乘以你愿意接受的手术时间(比如0.5秒)。这给出了您应该使用的迭代计数(在本例中为83,333)。

如果这个数字小于当年推荐的最低数量(我听说2012年有6.4万个，每两年翻一番)，那么你可能需要更强大的硬件。

Answer 3

你的想法和算法在我看来是可信的。根据摩尔定律，整数增加。每两年两次的表现是保守但很好的估计。顺便说一句，您应该在代码中添加一个注释来解释rational。未来的开发人员将会非常感激。

您应该记住，每一次额外的循环都会增加破解密码的难度，但也会使DDoS服务变得更容易。毕竟，PBKDF2消耗了大量的CPU资源。氪星更成问题。它的设计也需要更多的内存。

不过，几乎120 K的子弹有点过高。我正在使用一个库，它为PBKDF2-SHA-1和PBKDF2-SHA512提供了64k轮的建议。现在，我会从SHA256或SHA512开始，作为伪随机函数。对于相同的CPU时间，您需要更少的循环，并且键空间很大(32或64字节而不是20字节)。

此外，我建议对您的代码进行两次修改。

1)您可以测量当前硬件的性能，而不是固定和线性增长。在启动时，应用程序测量键派生函数的运行时间，并将循环次数增加5,000 (大约)，直到达到一个好的值为止。clock_gettime(CLOCK_PROCESS_CPUTIME_ID，res)给你很好的分辨率。当然，你需要确保轮数在合理的范围内。

2)当用户登录到您的站点时，将其密码散列的整数与当前的循环计数进行比较。如果值低于升级密码信息，则增加整数。毕竟，这是您唯一一次能够访问未散列密码。