我应该在散列密码时将散列函数名称存储在数据库中吗？

Question

关于保存用户密码的加盐哈希版本，我在DB中保存了哈希加盐的密码和在对其进行哈希之前使用的盐。

我是否还应该在数据库中保存用于散列加盐密码的算法的名称(例如，SHA1或MD5，我不打算使用MD5!)因此，如果有人发现我使用的算法存在漏洞，我可以为未来的用户切换使用另一种算法？

注意:我不是在谈论用于生成随机哈希的算法。

Answer 1

是的，这是个好主意。它的成本非常低(每个条目只需几个字节)，这意味着您可以在将来更改和改进密码的存储方式。例如，假设您几年前就开始在MD5中使用这种方法--现在升级到SHA1或其他更安全的方式将变得微不足道，只需在用户下次登录时更新每个用户的密码散列即可。

注意:你应该使用像PBKDF2这样的东西来散列你的密码，而不仅仅是一个加了盐的散列。

Answer 2

如果您一开始就使用强加密散列函数，则可能没有理由切换到更强的散列函数。

有一个网站keylength.com，它总结了关于计算信息安全的最重要的建议。目前，所选哈希函数的长度应为160位或更长--越多越好。

如果您正在寻找一种通用格式，您可以使用modular format，它包含散列函数的标识符、使用的盐、摘要和更多信息(例如，成本因素)，格式如下：

$<id>$[<parameters>$]<salt><digest>

Many suggest to use for passwords作为其额外的成本参数，用于调整散列的计算成本。

Answer 3

这是个人喜好中的一种。如果发现散列算法中存在缺陷，则需要更改用户密码的存储和验证方式。有多种方法可以做到这一点，存储散列的名称是一个有效的替代方案。假设

• 如果发现一个弱点，您希望切换到更好的散列替代方案
• 您没有存储明文密码(如果您存储了，则会遇到更大的问题)

您需要使用新的散列算法自动为您的用户生成新密码(并通知他们)，或者让他们在下次登录时更改或验证他们的密码。存储算法的方法有助于促进第二种选择(我认为这是更好的选择)。

从技术上讲，如果数据库被渗透，存储散列算法不会降低密码的安全性，并且当您希望更改算法时，它允许您提供更大的灵活性。