大多数服务、程序等都有各种密码复杂性检查。无需深入研究 efficacy of such checks ，我想到了一个可能很有趣但也可能有问题的检查:
“新密码必须是 Y 个字符，不同于最后的 X 个密码。”
这将阻止人们使用像 Password1! 这样的密码。 , Password2! ， 等等。但是，如果这样做了，就无法对以前使用的密码进行哈希处理——它们充其量只能被加密……对吗？
为小Y和一个相当短的密码，你可能仍然可以存储散列和暴力破解Y新密码的字母变体，但这变得不可行，因为 Y并且密码长度增加。
我最初的想法是这样的:因为当您更改密码时，您必须提供原始密码，散列新密码并以加密形式存储旧密码。现在是可逆的。
所以假设一个事件密码总是被散列，有没有更好的方法来做到这一点？并且是否会增加或减少应用程序的安全性？
最佳答案
我试图将其放在评论中，但我认为这很重要，可以提供答案。
OP 提出的方案不一定违反 CWE-257。该提案不允许系统管理员(例如)恢复旧密码。
提议是使用新密码作为所有旧密码的加密 key 。如果您可以接受存在于客户端而不是服务器上的“新密码验证”，那么这并不比使用密码加密任何其他内容安全。
因此，“更改密码”小工具将是客户端代码。服务器将发送 N 个较早密码的加密列表，客户端可以使用用户当前的密码对其进行解密，然后使用用户的新密码重新加密。服务器在任何时候都没有足够的信息来确定任何密码，无论是旧的还是新的。只有客户端拥有此信息，但无论如何它都有这些信息……不同之处在于，了解您当前密码的攻击者也可以了解您的旧密码。由于了解您当前的密码已经是一场灾难，这并没有让我觉得更糟。
确实，这并不能防止员工编写自己的密码更改实用程序来绕过密码限制的“攻击”，因为验证不是在服务器端完成的。但在我看来，这绝不是对 CWE-257 的违反。
这实际上是一个相当聪明的想法。
关于security - 检查密码复杂度 : different from last X passwords，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7265782/