我一直在寻找方法来保护我的用户密码。我目前正在使用哈希算法和随机盐的组合。如何保护加密密码即使是最弱的一个？
这个问题的主要原因是当我的用户设置一个非常非常弱的密码。无论我的混合哈希算法有多困难，以及我的盐有多久，我认为它可以在不到一年的时间内被破解。
我一直在想一个新的方式。我已经创建了一个脚本，每次用户通过在旧的散列密码上添加一个随机盐注销，然后再次加密，就会重新加密密码。所以，每次用户回来时，加密的密码都是不同的。得到它？
但是这个想法的主要问题是，每次用户注销时我都必须存储新盐。想象一下，如果用户每天都登录和注销，我的代码看起来就像：
有什么想法？
哦，我有一个想法。如何每年重新生成新的加密密码？
您的主要假设有两个问题。第一个是关于储存盐的问题。你已经为腌制密码解决方案做了。用你的新方法，盐会随着时间而改变，就是这样。所以你可以使用这种方法，并且唯一的额外成本是在每次登录时重新计算散列值（当你实际上拥有密码字符串本身时）。
第二个问题是更重要的问题：重新哈希不会改变任何东西。一旦攻击者获得了一个腌制散列值，就足以装入字典式攻击。事实上，你改变你的盐和数据库中的散列不会让它变得更困难。所以在创建第一个散列之后不需要重新计算散列。
重新加密不能解决您的问题。
你唯一能做的就是创建一个多部分哈希，并且希望攻击者不会得到所有这些哈希。我通常使用两部分盐：
一部分是随数据库中随机存储的每个用户值。
另一部分是每个应用盐。您可以将其存储在应用程序配置中或OS提供的特殊密码存储区中。
该拆分的优势在于，如果攻击者只是获得对数据库的访问权限是不够的，但他需要访问应用程序salt的存储位置。因此，例如，一个简单的SQL注入窃取你的数据库是不够的。如果攻击者可以执行代码，它可能根本没有任何帮助。
而且你应该使用一些方法来减缓哈希。典型的散列函数速度很快，所以蛮力也很快。但是，如果你迭代哈希函数一百万次，它仍然不会减慢有效的登录速度，但会大大减缓蛮力。
您可以使用Password Based Key Derivation Function（如PBKDF2）来实现此目的。
我明白了。所以这个想法是尽可能降低蛮力。我会尝试这一个。 – dimassony 2011-02-27 13:58:00
这是第二部分的想法。但是，当然，您的合法登录次数也会减少相同的因素。所以这是登录的计算成本和放慢攻击者之间的折衷。根据用户数量的不同，服务器应用程序可能需要10毫秒左右的时间，而磁盘加密时间则需要1秒左右。 – CodesInChaos 2011-02-27 14:10:15
您可以使用“密钥延伸”：在腌制后迭代哈希，例如，一百万次。 然后存储哈希值，盐值和迭代次数。 然后，攻击者每秒可能比每次散列一次检查密码减少百万次。但是一个非常短的密码仍然会下降：请注意，您自己要验证合法密码，需要执行相同的操作。假设你接受1秒的时间让自己检查，那么攻击者也可以在类似的机器上检查每个密码1秒的密码（如果他使用更多或更快的机器，则更多）。每个密码1秒仍然足以检查弱密码和短密码，标准字典等。实际上没有防御措施，只会让它更难。
只要使用很长的盐，或开始执行人民的密码标准。 – Marcin 2011-02-27 13:45:54