在更改应用程序的密码哈希算法时，系统应如何迁移已保存在数据库中的值？我很清楚我无法以散列形式迁移它们，但我需要输入数据才能计算新的散列。
有两种情况我可以访问输入数据：
显然，只有在其中一个过程中，我才能将新哈希保存到数据库中以迁移密码。
虽然我所有的同事都在投票支持方法一，但我的直觉告诉我不要那样做。有推荐的方法吗？
【问题讨论】：
我认为没有理由在登录时不这样做。你有理由不想做#1吗？您验证新的哈希，如果失败，验证旧的哈希算法。如果可行，那么我将在旧哈希上写入新哈希。这意味着您的密码将被更快地转换，因为用户登录的次数可能比更改密码的次数要多。除非你强迫人们这样做，否则我怀疑大多数人会自己改变它。
【讨论】：
如果您不想接触旧的身份验证代码（即切换到新框架）或只是想摆脱旧的密码字段，这里有一个替代解决方案：
备份现有的密码表，然后删除该表中密码列中的所有现有条目（当然必要时更新列类型），以便它准备好接收具有新加密的新密码.
下次用户尝试登录时，检查密码表，如果用户存在但没有密码，则提示他们“我们已经实施了系统范围的升级，所有帐户都需要已通过电子邮件重新验证。我们已向您发送了一封电子邮件，请使用该电子邮件完成您的帐户升级。对于给您带来的不便，我们深表歉意。"
用户将转到他们的电子邮件并单击可能显示“重新确认我的帐户”之类的链接。他们将被带到一个需要一些安全令牌参数的页面，该参数是从电子邮件中给出的链接接收的。此页面现在将要求他们输入用户名和密码（更重要的是密码）以完成升级。您可以要求他们输入两次密码，以防止输入错误。从技术上讲，您正在这里创建他们的密码。只需在标有“密码”和“确认密码”的 2 个输入中询问即可。
与其他解决方案相比，此解决方案当然也有 pro's 和 con's。好消息是您不必在新环境中添加旧的哈希代码并让它在那里直到有一天您的所有用户最终再次登录。但是这个解决方案也伴随着编写额外代码的代价（发送电子邮件/令牌等的代码）。您必须将该工作与您提议的解决方案所涉及的工作进行比较，即拦截传入的表单输入、检查旧散列，然后传递到新的身份验证代码。只是给你的另一个想法。
【讨论】：
看看这个IT场景：A公司接管了B公司，业务模式相似，所有的客户都需要合并到A公司拥有的一个更大的系统中，同时停用B公司不同密码哈希算法的用户系统， 完成此操作的最佳实施是通过注册的电子邮件地址为所有迁移的用户强制更改密码。
【讨论】：
如果不了解问题的具体情况，很难获得具体的建议。我将假设您想要更改密码存储策略的原因是因为您的新策略将比现有策略更加安全。
如果是这样，那么等待的可能优势是什么？这个想法是为了减轻现有的风险。实际上，用户很少更改密码。如果您想迁移到新的存储策略，您可能应该在登录时进行，否则您将拥有一个充满安全性可疑密码的大型数据库。
【讨论】：