重新散列散列密码

Question

假设知识
Hashing、Salting、PBKDF[1-2]

问题
我使用像 PBKDF2 这样的缩放散列/加盐算法在我的数据库中存储密码。我想‘嘿，如果我将密码散列 20000 次，那应该足够安全，可以抵御暴力攻击，对吗？它是真的。直到明年更好的电脑问世。

可能的解决方案

撇开加密密钥长度和盐长度的问题（也可以合并到这个解决方案中）我想，如果每 N 天，我重新散列数据库中的所有密码会怎样。所以它们被散列了 20,000 次，然后一周后，我又对它们进行了 500 次散列，使它们总共 20,500 次。将它在数据库中散列的次数存储在某处。这个想法是随着技术的进步增加哈希计数。

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

任何人都可以看到这个问题吗？这个已经试过了？是否有一种算法可以接受预先散列的密码并将其重新散列“N”次？

编辑
问题不是多重散列是否安全（这已经过尝试和测试）。问题是重新散列以提高安全性，而不必让用户重新设置他们的密码

解决方案：礼貌与 JVestry 讨论

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

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

谢谢！

TTD

Answer 1

Can anyone see a problem with this?

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

黑客只需在第 x 周进行这么多迭代即可。一旦密钥被损坏，他/她只需像您每周那样对它进行哈希处理即可。这非常容易并且完全被忽视。

如果您重新哈希，请使用新的盐并从头开始进行更多迭代。你的捷径并不能带来额外的安全。