database - 重新散列散列密码

Question

假设知识
散列，加盐，PBKDF[1-2]

问题
我使用像 PBKDF2 这样的缩放散列/加盐算法将密码存储在我的数据库中。我想'嘿，如果我将我的密码散列 20000 次，那应该足够安全，对吧？这是真的。直到明年更好的计算机问世。

可能的解决方案

撇开加密 key 长度和盐长度(也可以纳入此解决方案)的问题不谈，我想，如果每隔 N 天，我会重新哈希数据库中的所有密码。所以它们被散列了 20,000 次，然后一周后，我又散列了 500 次，使它们总共散列了 20,500 次。将它被散列的次数存储在数据库中的某个地方。这个想法是随着技术的进步增加哈希计数。

现有的类似实现
BCrypt引入了一个工作因素来增加散列密码所需的时间:
PBKDF2使用多次迭代来做同样的事情。这被 Mac OS-X、windows 和 linux 用于文件级加密。 Wi-Fi 网络也使用它的实现。

有人能看出这有什么问题吗？这已经尝试过了吗？是否有一种算法可以接受预先散列的密码并将其重新散列“N”次？

编辑
问题不在于多重散列是否安全(这已经过尝试和测试)。问题在于重新散列以提高安全性而不必让用户重新设置密码

解决方案:由与 JVestry 的讨论提供

因此，每“N”天重新散列所有密码是浪费时间，因为黑客可以使用数据库的旧副本破解密码。 但是，如果您将随时间增加哈希计数的概念与密码更新策略相结合，这个概念是合理的。

实现
所有密码每 30 天过期一次。当它们被更新时，它们的哈希计数器会增加。因此，昨天重置的密码将比 20 天前设置的密码更难破解。哈希计数器可以使用最后修改日期存储或从算法中派生。

谢谢!

时差

Answer 1

Can anyone see a problem with this?

是的。假设您每周用盐重新散列(我相信这就是您的意思)，仍然存在问题。如果有人在第 x 周设法访问了散列密码，那么在第 x + n 周进行的任何进一步散列都不会提供任何额外的安全性。

黑客只需在第 x 周进行如此多的迭代。一旦 key 被破坏，他/她只需要像你每周做的那样多一点散列。这非常容易，而且完全没有引起注意。

如果您重新散列，请使用新盐并从头开始进行更多迭代。您的快捷方式不会带来额外的安全性。