长期以来，散列函数需要一个工作因素，以保持操作“足够慢”以在数据库泄漏的情况下保护个人密码。Bcrypt 和 PBKDF2 是值得注意的例子。

在安全性方面，我也知道“不要自己动手”，但很容易想象这样一种情况，随着时间的推移，由于硬件增加，密码散列方案的工作因素变得过快。人们还可以想象这样一种情况，数据库所有者升级他们自己的硬件，因此与硬件升级之前使用的相比，更高的工作因数是合适的，以确保每个密码更好的安全性。

问题在于必须“重新散列”密码，因为您不想在数据库中存储明文甚至加密密码，因此系统无法再次访问密码以重新散列以更改工作因素. 要解决这个问题，只需在用户登录时重新进行哈希处理。每当用户登录时，系统已经可以使用他们的明文密码，在密码的成功哈希验证后，系统可以检查与之前关联的工作因素密码的哈希值（在 bcrypt 中很容易做到），如果它小于系统操作员选择的标准工作因子，那么明文密码将被重新哈希并与新的工作因子和新盐一起存储。会话不需要重置，因为使用的密码和以前一样，只是不同的工作因素和盐。

除了在密码验证过程中明文密码在内存中的时间稍长以及每当发布工作因子增加时验证密码的时间增加之外，我找不到该模型的任何故障。有没有我遗漏的安全漏洞？