显然，某种限制登录尝试的机制是安全要求。虽然我喜欢尝试之间的时间呈指数增长的概念，但我不确定存储信息的内容。我也对替代解决方案感兴趣，最好不包括验证码。
我猜由于阻止 cookie 或自动清除它们，cookie 将无法工作，但会话会起作用吗？还是必须将其存储在数据库中？不知道可以/正在使用哪些方法，所以我根本不知道什么是实用的。
16147 次
8 回答
20
使用用户表“failed_login_attempts”和“failed_login_time”中的一些列。第一个在每次登录失败时递增，并在成功登录时重置。第二个允许您将当前时间与上次失败时间进行比较。
您的代码可以使用数据库中的这些数据来确定等待锁定用户的时间、允许登录之间的时间等
于 2009-02-24T05:18:36.870 回答
7
假设谷歌已经完成了必要的可用性测试（不是一个不公平的假设）并决定使用 captchas ，我建议与他们一起去。
当我是一个真正的用户并且忘记了我的密码时，增加超时令人沮丧（有很多网站及其相关密码发生了很多，尤其是对我而言）
于 2009-02-24T05:16:46.533 回答
5
在数据库中存储尝试是最好的解决方案恕我直言，因为它为您提供了安全漏洞尝试的审计记录。根据您的应用程序，这可能是也可能不是法律要求。
通过记录所有错误的尝试，您还可以收集更高级别的信息，例如请求是否来自一个 IP 地址（即某人/事物正在尝试暴力攻击），因此您可以阻止该 IP 地址。这可能是非常有用的信息。
一旦您确定了一个阈值，为什么不强迫他们要求将电子邮件发送到他们的电子邮件地址（即类似于“我忘记了我的密码”），或者您可以采用 CAPCHA 方法。
于 2009-02-24T05:17:02.600 回答
5
这篇文章中的答案优先考虑以数据库为中心的解决方案，因为它们提供了一种使审计和锁定逻辑方便的记录结构。
虽然这里的答案解决了对个人用户的猜测攻击，但这种方法的一个主要问题是它会使系统容易受到拒绝服务攻击。来自世界的任何请求都不应触发数据库工作。
应在 req/res 周期的早期实施替代（或附加）安全层，以保护应用程序和数据库免于执行昂贵且不必要的锁定操作。
Express-Brute是一个很好的例子，它利用 Redis 缓存过滤掉恶意请求，同时允许诚实请求。
于 2017-06-28T15:37:08.277 回答
2
您知道哪个用户 ID 被击中，保留一个标志，当它达到阈值时，只需停止接受该用户的任何内容。但这意味着您为每个用户存储一个额外的数据值。
我喜欢尝试之间的时间呈指数增长的概念，[...]
您实际上可以在连续尝试之间随机延迟，而不是使用指数增加的时间。
也许如果您解释您正在使用的技术，这里的人们将能够提供更具体的示例。
于 2009-02-24T05:17:03.223 回答
2
锁定政策一切都很好，但有一个平衡点。
一个考虑因素是考虑用户名的构造 - 可以猜测吗？可以列举出来吗？
我正在对一个带有员工门户的 dotcom 进行外部应用程序笔测试，该门户网站为 Outlook Web Access /Intranet 服务、某些应用程序提供服务。枚举用户很容易（网站本身的执行/管理团队，以及通过谷歌、Facebook、LinkedIn 等）。一旦您获得了用户名登录的格式（名字然后姓氏作为单个字符串输入），我就有能力将 100 名用户拒之门外，因为他们的 3 次罢工和淘汰政策。
于 2009-02-26T13:40:56.117 回答
1
存储信息服务器端。这将使您还可以防御分布式攻击（来自多台机器）。
于 2009-02-24T05:17:12.240 回答
1
您可能想说阻止登录一段时间，例如 3 次失败尝试后的 10 分钟。成倍增加的时间对我来说听起来不错。是的，将信息存储在服务器端会话或数据库中。数据库更好。没有cookies业务，因为它很容易被用户操纵。
您可能还希望将此类尝试映射到客户端 IP 地址，因为当其他人试图通过失败尝试猜测有效用户的密码时，有效用户很可能会收到一条被阻止的消息。
于 2009-02-24T05:25:18.523 回答