我以前必须两次解决同样的问题：

1. 我的第一个 Web 应用程序，我实际上知道足够 MD5 散列用户的密码；然而，我不知道盐，后来才开始研究。
2. 几年后，当我决定从现有的 MD5“升级”到 SHA-512 时，实际上是同一个网络应用程序。

在这两种情况下，我都没有使用您的选项，而是使用选项 3：在用户下次登录时，使用密码生成新哈希并替换旧哈希（在验证旧哈希之后）。

在添加盐的情况下，这非常简单：我所做的只是默认每个人都使用“”（空字符串）的盐，可以将其连接起来然后进行散列，而不会对生成的散列产生任何影响；一旦通过身份验证，我为用户生成了一个新的盐，然后重新散列密码，保存新的结果。

从 MD5 升级到 SHA-512 有点棘手，但只需查看表中 has 的字符串长度（我没有为新哈希使用新列，只是扩展现有列以适应更长的哈希）我可以告诉使用哪种算法，然后适当地验证用户；一旦通过身份验证，如果它们仍然在旧哈希上，我会计算一个新的（也借此机会生成一个全新的盐）并存储它。

在这两种情况下，我当然最终都遇到了“旧式”密码仍然存在的情况。在等待适当的时间（例如 6 个月）后，只需确定那些自采用新样式以来尚未登录的人是“不活动的”：为他们生成并存储一个新的、完全随机的密码（使用新样式存储它，当然），如果他们真的回来了，他们将不得不使用您的密码重置机制来重新获得访问权限。（或者，保持原样，但只需删除旧样式的代码即可有效地使其无效。）您也可以（如果适用）向这些用户发送电子邮件，要求他们登录以完成安全升级他们的帐户，在使他们的当前密码无效之前。

当然，这种方法确实涉及身份验证例程中的额外代码，但这只是暂时的——一旦每个人都升级了（无论是通过登录还是像上一段那样被“强制”进入），您就可以删除所有负责的代码执行升级。安全升级完成，您的大多数用户（以及所有普通用户）从未注意到任何事情！

我之前在需要做同样事情的公司中使用过选项 2。选项 1 没有问题，但 2 似乎更简单。

也使用PBKDF2，bcrypt而不是 SHA-512 作为密码

好的 Open-ID 已经过时了，但是您可以使用 O-Auth 并使用 Twitter 或 Facebook 连接之类的东西，并完全消除存储和管理用户名和密码吗？

这不是一个真正的答案，因为它没有解决您的具体问题，但我同意添加另一个联合您的 ID 的选项。因此，无论是 OpenID、Facebook、谷歌，还是……安全存储用户凭据的最佳选择就是干脆不这样做。

TL;DR：如果/可能的话，联合身份验证。

不要做选项 1，你会失去更好的散列算法的所有好处。通过首先使用更差的算法进行散列，然后使用更好的算法：

• 你失去了 sha512 的所有碰撞阻力。如果md5(password1) == md5(password2)，那么sha512(md5(password1)) == sha512(md5(password2))。我不是安全研究人员，但是由于您要进行多次散列，我怀疑您实际上会增加碰撞的机会（md5 碰撞的机会 + sha + md5 碰撞的机会）。

• 出于同样的原因，额外的位（512 对 128）毫无价值。散列 128 位信息永远不会给你超过 128 位的熵。