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