Algorithm 在对密码进行哈希运算时，是否应将哈希函数名存储在DB中？

关于保存用户密码的salt散列版本，我将散列salt密码和散列之前使用的salt保存在数据库中

我是否也应该在数据库中保存用于散列加密密码的算法名称（例如SHA1或MD5[我不打算使用MD5！]），以便在有人发现我使用的算法存在漏洞时，我可以为未来的用户切换到另一种算法

---

注意：我不是说生成随机散列的算法。

如果首先使用强加密散列函数，可能没有理由切换到更强的散列函数

该网站总结了计算机信息安全方面最重要的建议。目前，所选哈希函数的长度应为160位或更大–越长越好

如果您正在寻找一种通用格式，则可以使用包含哈希函数标识符、使用的salt、摘要和其他信息（如成本因素）的格式：

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

$$[$]

---

因为它的额外成本参数是调整散列的计算成本。

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

• 如果发现缺陷，您希望切换到更好的哈希替代方法
• 您没有存储明文密码（如果存储明文密码，则会遇到更大的问题）

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

---

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

是的，这是个好主意。它花费您很少（每个条目几个字节），并且意味着您可以在将来更改和改进存储密码的方式。例如，假设您几年前开始在MD5中使用此方法，那么现在升级到SHA1或其他更安全的方法就变得很简单了，方法是在每个用户下次登录时更新他们的密码哈希

---

请注意，您应该使用类似于散列密码的东西，而不仅仅是盐散列。

在发现MD5或SHA1中的第一个漏洞之前，您在第一句话中给出的建议同样有道理。依靠当前的加密原语无限期地保存密码是一种糟糕的策略。请使用bcrypt或scrypt存储密码。