关于保存用户密码的加盐散列版本，我将散列加盐密码和散列之前使用的盐保存在数据库中。
我是否还应该将用于散列加盐密码的算法名称保存在数据库中（例如 SHA1 或 MD5 [我不会使用 MD5！]），以便在有人发现我使用的算法存在漏洞的情况下，我可以为未来的用户改用另一种算法吗？
注意：我不是在谈论用于生成随机哈希的算法。
【问题讨论】：
标签： algorithm hash passwords password-protection salt
是的，这是个好主意。它花费很少（每个条目几个字节），这意味着您可以更改和改进将来存储密码的方式。例如，假设您在几年前就开始在 MD5 中使用这种方法 - 现在升级到 SHA1 或通过在用户下次登录时更新每个用户的密码散列来更安全的其他方法变得轻而易举。
请注意，您应该使用 PBKDF2 之类的东西来散列您的密码，而不仅仅是加盐散列。
【讨论】：
如果您一开始就使用强加密散列函数，则可能没有理由切换到更强的散列函数。
有一个网站keylength.com 总结了计算中信息安全的最重要建议。目前，选择的哈希函数应该有 160 位或更长的长度——越多越好。
如果您正在寻找一种通用格式，您可以使用modular crypt format，它包含哈希函数的标识符、使用的盐、摘要和更多信息（例如成本因素），格式如下：
$<id>$[<parameters>$]<salt><digest>
Many suggest to use bcrypt for passwords作为它的附加成本参数是为了调整散列的计算成本。
【讨论】：
这是个人喜好之一。如果发现散列算法的弱点，您将需要更改用户密码的存储和验证方式。有多种方法可以做到这一点，存储散列的名称是一种有效的替代方法。假设
您需要使用新的哈希算法为您的用户自动生成新密码（并通知他们），或者让他们在下次登录时更改或验证密码。存储算法的方法有助于促进第二种选择（我认为这是更好的选择）。
从技术上讲，如果数据库被入侵，存储哈希算法不会降低密码的安全性，并且当您希望更改算法时，它可以为您提供更大的灵活性。
【讨论】：