诚然，由于好的服务器从不存储密码，只存储密码验证令牌（即哈希），那么它们无法在没有用户合作的情况下更改哈希函数。通过要求用户重新输入他们的密码，他们告诉他们已经以适当的方式存储了密码（或者，至少，不是以一种非常脆弱的方式）。

但是，通过电子邮件要求用户重新输入他们的密码（按照后续电子邮件中的说明）是非常糟糕的做法。应该训练用户永远不要做这样的事情。该机构正在取消多年的患者教育努力。此外，不应有“特殊说明”：更新哈希函数的过程应在用户下次登录时自动透明。我发现用户当时应该做任何特别的事情是非常可疑的——除非他们计划执行这些可怕的“密码策略”之一，它将拒绝不包含两种大小写字母、数字、标点符号的密码以及来自不同经文的两个梵文单词。

在我看来，更新密码散列的散列函数的正确方法是在很长一段时间（几个月）内透明地进行，并简单地“锁定”在整个期间未使用的帐户。如果需要让用户真正立即连接，请发送电子邮件说明“您的帐户已在 6 个月内未使用；出于安全原因，如果您在下个月内未连接，它将被禁用，并且必须通过服务台处理重新激活”。

@CodesInChaos 建议“链接”散列，即使用旧散列值作为新散列值的“密码”，至少以暂时的方式。只要满足以下所有条件，这就会起作用并提供新哈希的安全优势：

• 旧的散列“足够好”（例如，它是密码上的 MD5，而不是旧的基于 Unix DES 的散列，它将密码截断为八个字符）；
• 您有一个地方可以存储旧哈希的额外参数（盐，迭代计数......）以及新哈希的参数（或者它们具有相同的格式，因此可以共享）；
• 您准备好在验证密码时承担计算这两个哈希函数的 CPU 成本；
• 如果正在转换（即您希望链散列只到该用户的下一次登录），那么有一种方法可以将存储的散列标记为“过渡”，以便验证者知道它必须计算旧散列然后新哈希。

所以这取决于旧功能是什么，新功能是什么，以及为什么要更改它。当前一个哈希是对 MD5 或 SHA-1 的简单、无盐、非迭代调用时，链接哈希当然是一个好主意。

我同意托马斯的观点。使用新算法突然重新创建哈希是没有道理的。除非存在数据库泄漏或使哈希可逆的新漏洞。

另一方面，如果别无选择，只能立即更改算法，那可能就是您的做法。您通知您的用户，以便他们有时间与您进行验证并检查这不是网络钓鱼尝试。然后设置一个安全平台来更改所有用户的密码。当然有人可以冒充管理员并使用虚假地址发送后续电子邮件，但第一封电子邮件似乎试图教育人们，他们不会上当，罪魁祸首很容易找到并且可以有效地采取对策，从而使模仿无利可图。

一个好的策略是强迫用户每 3 个月左右更改一次密码。这是一种痛苦，但它被认为是一种很好的做法是有原因的，人们倾向于在任何地方使用相同的密码，或者把它写在纸上或手机上。如果有足够的时间，这些支持被破坏的风险就会变得很大。在我的公司，我们必须每 3 个月更改一次，我们不能使用旧密码，并且新密码应该与旧密码足够不同（即：不要只添加一个字符..）。

不过这很痛苦，密码通常是这样的。我非常喜欢使用 OTP 令牌进行单点登录 (SSO)。易于撤销、易于用户使用、只有一个支持等。但这样的基础设施是有代价的，通过定期更改密码让员工的生活稍微复杂一点是一个很好的业务解决方案。