我正在为应用程序编写一个全面的身份验证系统，并计划记录失败的身份验证尝试以实现更好的安全性。我想检查暴力破解和字典攻击的失败密码，但是我能想到的唯一方法是存储原始密码。
我对这样做的感觉很复杂。虽然我知道失败的登录尝试会经常被清除，但我不喜欢将原始密码存储在数据库中的想法。我知道我经常输入错误的密码，这些密码与我的真实密码非常相似，或者更糟糕的是，我会为特定登录输入错误的密码，而该密码实际上是我所属的另一个网站的有效密码。
但是，如果不存储一些原始密码，就不可能实现高级安全性，所以我正在尝试考虑最好的方法。
以下是我想到的一些可能的解决方案：
有人对此有任何意见吗？这是一个好/坏主意吗？我应该使用双向加密吗？
【问题讨论】：
正如其他人所指出的，存储纯文本密码是一个非常坏主意，而限制/限制登录尝试是正确的方法。
如果您担心密码的安全性，那么您应该在创建密码时实施密码策略，而不是在身份验证时。然后，您可以在内存中检查字典单词并制定典型策略，例如最小长度、必须包含数字、大写字母等。
当然，密码策略可能会让用户感到烦恼，但理论上它们可以缓解您对弱密码的担忧。
丑陋的事实是，密码不是证明身份的糟糕方法，但替代方法更昂贵、更麻烦。
【讨论】：
如果您真的想保留有关密码的任何信息，您可以存储失败密码的哈希值。它不允许您手动分析模式，但允许将失败的尝试相互比较。
也就是说，我认为分析密码不会产生任何有用的信息。
【讨论】：
【讨论】：
你有没有想过一定数量的登录然后是一个定时块？如果登录失败 3x/5x/10x 如果您愿意，则将帐户完全锁定指定时间。
这样做会让暴力破解者使用起来非常费力，以至于他们可能不会费心去尝试。记录每一次失败的尝试，甚至想到纯文本密码也是一个坏主意。而是使用以下类比：
"If I make my house so difficult to get into, they'll try the neighbours first."
让蛮力者的生活变得困难，他们不会打扰。
另一个选项是在一定数量的登录失败后，添加captcha。如果验证码很好，这又会极大地阻碍他们的进步。
HTH，
凯尔
【讨论】：
这似乎是过度设计。我只会跟踪失败的登录尝试并在 $x 次失败的登录尝试之后，然后阻止 IP 尝试再次登录 1-24 小时左右。
如果您担心有人针对特定帐户，您可以记录特定用户名的失败尝试次数，然后采取适当措施，例如将该用户名的失败登录次数限制为每 24 小时在任何 ip 上的 2 或 3 次地址。
我可以想办法尝试通过比较来检测字典/暴力攻击，但是您必须收集用户输入并将其与之前的尝试进行比较，如果您稍微存储，这可能是一个安全问题在数据库中拼写错误的合法密码。此外，每次登录都会占用大量 CPU 资源。
目标应该是让暴力攻击者的速度变得非常缓慢，但不会让合法用户感到烦恼或妥协。
虽然现在我正在考虑更多，但预防方法也可能是一种通过锁定用户无法登录来拒绝服务的方法，所以请记住我的建议。
【讨论】：
当您提到存储原始密码时，我不确定您的意思 - 大概您只想以纯文本形式存储失败的密码尝试以分析模式（字典攻击）和容量（蛮力）。
在我的有限经验中，您将获取用户输入的密码，对其进行散列（使用盐，用于散列存储密码的相同盐）并与存储的散列值进行比较。如果验证失败（散列值不相等），记录用于尝试的纯文本版本的密码。
我还建议在尝试一定次数的失败尝试后锁定帐户，并且可能有一个指数超时窗口，以便再次尝试登录尝试。如果用户在开始时输入了错误的密码，但随后又正确输入了密码，您可能会考虑删除为该特定会话的失败登录而捕获的密码。
【讨论】：
根据您选择的身份验证协议，例如Kerberos，您甚至可能无法访问输入的密码。
【讨论】：
正如您自己指出的那样，记录原始密码似乎是一个非常糟糕的主意。
您能否只记录用户名和登录失败的次数，而不实际记录密码？如果在短时间内有数百次登录尝试，如果存在暴力攻击，那将是相当明显的。您还可以记录 IP 地址。
【讨论】：
用户犯错与暴力/字典攻击之间有很大区别：请求量。不要存储失败的尝试——你说得对，明文密码应该被最低限度地处理——只要看看尝试的模式。这应该是足够的数据。
除此之外，您的“高级安全性”开始看起来像“高级攻击向量可能性”。
【讨论】：