我一直在寻找保护用户密码的方法。我目前正在使用散列算法与随机盐的某种组合。
这个问题的主要问题是当我的用户设置了一个非常非常弱的密码时。不管我的混合哈希算法有多难，我的盐有多长，我认为它可以在不到 1 年的时间内破解。
我一直在想一个新的方法。我制作了一个脚本，每次用户注销时都会重新加密密码，方法是在旧的散列密码上添加随机盐，然后再次加密。所以，每次用户回来，加密的密码都是不同的。得到它？
但是这个想法的主要问题是，每次用户退出时我都必须存储新的盐。想象一下，如果用户每天登录和注销，我的代码会是什么样子？
任何想法？
哦，我有个主意。每年重新生成新的加密密码怎么样？
重新加密对您的问题没有帮助。
你唯一能做的就是创建一个多部分哈希，并希望攻击者没有得到所有这些。我通常使用两部分盐：
一部分是与密码一起存储在数据库中的每个用户的随机值。
另一部分是每个应用程序的盐。您可以将其存储在应用程序配置或操作系统提供的特殊密码存储中。
这种拆分的优势在于，攻击者仅获得对数据库的访问权限是不够的，但他需要访问存储应用程序 salt 的任何位置。因此，例如一个简单的 sql 注入窃取您的数据库是不够的。如果攻击者可以执行代码，它可能根本无济于事。
你应该使用一些方法来减慢哈希。典型的哈希函数很快，所以蛮力也很快。但是，如果您将哈希函数迭代一百万次，它仍然不会减慢有效登录的速度，但会大大减慢暴力破解的速度。
您可以使用基于密码的密钥派生函数（例如 PBKDF2）来实现这一点。
您可以使用“密钥拉伸”：在加盐之后迭代哈希，例如一百万次。然后存储哈希值、盐和迭代计数。然后，攻击者每秒检查的密码可能比您哈希一次时少一百万倍。但是一个很短的密码还是会掉：注意你自己，要验证密码的合法性，需要做同样的操作。假设您接受 1 秒的时间让自己检查，那么攻击者也可以在类似的机器上以每个密码 1 秒的时间检查密码（如果他使用更多或更快的机器，则更多！）。每个密码 1 秒仍然足以检查弱密码和短密码、标准字典等。确实没有防御它，只会让它变得更难。
你的主要假设有两个问题。第一个是关于储存盐的问题。您已经为加盐密码解决方案做了。使用您的新方法，盐会随着时间而改变，仅此而已。因此，您可以使用这种方法，唯一的额外成本是在每次登录时重新计算哈希值（当您实际上拥有密码字符串本身时）。
第二个问题是更重要的一个：重新散列不会改变任何事情。一旦您的攻击者获得一个加盐哈希值，就足以发起字典攻击。您更改数据库中的盐和哈希的事实不会使其变得更加困难。因此，在创建第一个哈希后无需重新计算哈希。