你不能。您的用户这样做是因为重置机制对他们完成工作来说变得很突兀。人们足够聪明，可以绕过你要设计的任何机制。那些不是的人会很快从那些人身上学到东西。像这样的信息传播得很快。

如果您以某种方式想出如何应对人们常用的密码 1 密码 2 密码 3 方案，您几乎会立即遇到一个新方案。1 密码 2 密码 3 密码。现在您看到了一个新模式，只需迭代所有数字。所以用户想出了一个更好的方案。密码A 密码B 密码C. 你会花费数周时间想出对策，却在 10 分钟内被一个想到你没有想到的聪明人打败。

关键是，用户通过您的反措施的能力和成本远远超过您不断开发新方案以试图阻止它们的能力。

解决方案只是停止将您的用户视为您试图击败的对手。他们不是。用户只是想把事情做好，而你为此设置了障碍。如果这真的让您非常困扰，您需要调整您对用户的态度，并与他们一起提出适合您的需求并且不会产生对抗关系的东西。

很简单：您有一个预期密码“password1”。测试“password”和“password0”以查看它们是否适用于旧哈希。无需查看旧密码的明文即可使用。

但是，由于史蒂夫·塞瑟（Steve Sether）提出的原因，这将行不通。

这已经在各个方面进行了讨论，并且大多数讨论似乎都回到了密码拓扑的概念——许多密码所具有的模式。YouTube 上有一个很好的OWASP 演示文稿，它表明许多必须遵循复杂性规则的密码遵循类似的模式：

• 密码1！- 如果你强制从大写字母、小写字母、数字和特殊字符中选择至少一个字符，很多人会选择一个大写单词，后跟一个数字，最后是特殊字符，通常是?，!, 或.- 拓扑是UL+DS（使用一种正则表达式样式语法）
• Password1 - 如果你不强制使用特殊字符，你通常不会得到一个
• password1 - 如果你不输入大写字母，你通常不会得到一个，但如果你这样做，它会在开头
• qwertyuiop - 如果您不强制执行任何操作，您会得到易于输入的内容

关于定期更改密码的价值也存在一些争议，因为它们往往会鼓励您所看到的行为。但是，由于业务选择的速度相对较慢，有时需要它们。

这产生了不仅要执行密码更改，还要执行密码拓扑更改的建议。密码重置过程变为：

1. 用户输入旧密码（例如Password1!），并MyS3cret$以重置形式输入新密码（ ）
2. 系统计算旧密码（UL+DS）和新密码（ULUDL+S）的拓扑结构
3. 如果拓扑匹配或新密码与复杂性规则不匹配，系统将拒绝密码更改

也可以完全拒绝某些常见的拓扑 - 也许您不想要任何Password1!形式的密码，在这种情况下，您将系统配置为拒绝任何具有拓扑的密码UL+DS。

永远不要用它来存储密码的拓扑结构——如果你的数据库被入侵，你会给攻击者一个绝妙的方法来减少他们破解恢复密码的努力。

请记住，用户仍然会想出一些方法来制作弱密码：他们可能会开始交替使用Password1!和!2Password，但这表明密码更改频率太高了。

防止用户更新与以前使用的密码过于相似的新密码（例如，仅单个数字/字符更改）的特定问题是直接的。

在同一个密码更改屏幕上，只需要求用户输入他们的旧密码以及他们请求的新密码。无论如何，要求用户在密码更改屏幕上输入他们现有的密码是一种很好的做法（这可以防止有人在无人看管的情况下短暂地让他们的帐户登录，让攻击者更改他们的密码，并在将来授予自己访问权限同时锁定真实用户）。

如果您可以在服务器端检查以下所有内容是否正确，则仅接受新密码：

1. 旧密码的哈希值与数据库中存储的哈希值相匹配。
2. 新密码满足您的强度要求（可能是所有一种字符的长密码；或具有特殊字符、大写字母、数字且至少为 8 个字符），
3. 旧密码和新密码（您刚刚以明文形式收到这两个密码，而没有以明文形式保存在数据库中）具有不错的编辑距离（比如大于 4）。如果距离不够，向用户反馈密码与之前的密码太相似，应该完全不同。
4. 新密码与任何以前使用的过期哈希都不匹配。（不允许密码重用旧密码）。

请注意，这不会阻止确定的用户做

<password>1-> <other password>1-> <password>2-> <other password>2。

如果你真的想阻止这种模式，你可以针对一些非常具体的模式来做。也就是说，每次保存密码时，您都可以对当前密码的一些常见修改进行哈希处理，并将它们作为以前使用的过期哈希值保存在数据库中。这可能会阻止一些常见的方案（例如，尾随数字），但用户会找到绕过它们的方法（例如，在密码中间增加一个字符）。