假设知识
Hashing，Salting，PBKDF[1-2]
问题
我使用缩放的散列/ salting算法（如PBKDF2）将密码存储在我的数据库中。我想'嘿，如果我把我的密码哈希20000次，这应该足以抵御暴力攻击吗？'这是真的。直到明年更好的电脑问世。
可能的解决方案
不考虑加密密钥长度和盐长度（也可以纳入此解决方案）的问题，我想，如果每N天，我会重新哈希数据库中的所有密码。所以他们被哈希了20,000次，然后一周之后，我再哈哈他们500次，总共20,500次。将其在数据库中进行哈希处理的次数存储在某处。这个想法是随着技术的进步增加哈希计数。
现有的类似实施
BCrypt引入了一个工作因素来增加散列密码所需的时间：
PBKDF2使用多次迭代来执行相同的操作。 Mac OS-X，Windows和Linux使用它进行文件级加密。 Wi-Fi 网络也使用它的实现。
有人能看到这个问题吗？这已经尝试过吗？是否有一个算法可以接受预先调整过的密码并重新散列'N'次？
修改
问题不在于多次散列是否安全（已经过尝试和测试）。问题在于重新散列以提高安全性，而不得不让用户重新设置密码
解决方案：与JVestry讨论提供
因此，每隔“N”天重新散列所有密码是浪费时间，因为黑客可以通过使用数据库的旧副本来破解它。 但是，如果将哈希计数随时间增加的概念与密码更新策略结合起来，那么这个概念就是合理的。
实施
所有密码每30天到期。当它们被更新时，它们的哈希计数器会增加。因此昨天密码重置将比20天前更难破解。哈希计数器可以使用上次修改日期存储或从算法派生。
谢谢！
TTD
答案 0 :(得分：3)
Can anyone see a problem with this?
是。假设你每周都要用盐（我认为这就是你的意思）重新进行，那么仍然存在一个问题。如果有人设法在第x周访问散列密码，那么第x + n周的任何进一步散列都不会提供任何额外的安全性。
黑客只需要在第x周进行如此多的迭代。一旦密钥被破坏，他/她只需要像每周一样对它进行哈希处理。这很简单，完全不被注意。
如果你重新使用，请使用新的盐并从头开始进行更多迭代。您的快捷方式不会带来额外的安全性。
答案 1 :(得分：2)
这会使蛮力破坏更加困难，但也会使登录过程变慢。
你最好少用盐。