好吧，我建议 BCrypt 优于 PBKDF2。

话虽如此，您的解决方案应该是双重的。

1. 为了立即保护系统，是的，您的解决方案很好。将 MD5 视为输入密码，并按照您的建议使用每个用户的盐。

2. 我建议将 MD5 移出图片。（除非这是严格的遗留应用程序）

   下次用户登录时，您的应用程序将可以访问未散列的密码，并能够使用跳过 MD5 步骤的密码更新散列。您必须在帐户上设置一些指标，以确定这是否已完成。

我还建议在输入密码（或 MD5）之前添加 Pepper 作为额外的安全预防措施。

BCrypt 对密码有最大长度，因此最好将输入密码与 Pepper 组合首先放在 SHA-256 哈希中。我不确定 PBKDF2 是否有这个限制。最终，你有一天可能会使用一个更新的哈希值，它也没有这个限制。

你知道，真的，可能没有必要从 MD5 迁移，但摆脱 MD5 将是获得最佳抗碰撞性的理想解决方案，并且看起来像是一个更清洁的设计。

正如 George 所说，这个系统目前还不错（假设您对 PBKDF2 使用了良好的盐和良好的迭代次数）。但是，您需要为系统增加灵活性，以应对密码验证算法的未来更新。虽然您当前的方案具有无需实际密码即可更新密码验证器安全性的优点，但拥有一个可让您查看特定验证器的算法的值仍然是一个好主意。

您可能需要这个的时间：

1. 如果您进行一些仅基于旧验证器无法完成的验证器更新，则在用户登录之前您将无法处理每个密码，因此您将有一些使用新算法的密码验证器和一些使用一个较旧的。
2. 如果您必须从备份中恢复，最好您的身份验证代码可以识别并支持旧版验证器。使您无需确保使用正确版本的代码库来与备份 auth DB 的时间相匹配。