限制（和记录）登录尝试的最佳方法

Question

显然，某种限制登录尝试的机制是安全性必备条件。虽然我喜欢尝试之间指数增加的时间概念，但我不确定存储信息。我也对替代解决方案感兴趣，最好不要使用验证码。

我猜测由于阻止cookie或自动清除cookie而无法使用cookie，但会话会有效吗？或者是否必须存储在数据库中？不知道可以使用什么方法，所以我根本不知道什么是实用的。

Answer 1

在users表'failed_login_attempts'和'failed_login_time'中使用一些列。第一个按登录失败递增，并在成功登录时重置。第二个允许您将当前时间与上次失败时间进行比较。

您的代码可以在数据库中使用此数据来确定等待锁定用户的时间，允许登录之间的时间等

Answer 2

假设谷歌已经完成了必要的可用性测试（不是不公平的假设）并决定使用验证码，我建议一起使用它们。

当我是一名真正的用户并且忘记了我的密码时，增加超时是令人沮丧的（有很多网站及其相关密码发生了很多，特别是对我而言）

Answer 3

在数据库中存储尝试是最佳解决方案恕我直言，因为它为您提供安全漏洞尝试的审计记录。根据您的申请，这可能是也可能不是法律要求。

通过记录所有不良尝试，您还可以收集更高级别的信息，例如，如果请求来自一个IP地址（即某人/某物正在尝试暴力攻击），那么您可以阻止IP地址。这可能是非常有用的信息。

一旦确定了阈值，为什么不强迫他们要求将电子邮件发送到他们的电子邮件地址（即类似于“我忘记了密码”），或者您可以采用CAPCHA方法。

Answer 4

锁定政策一切顺利，但存在平衡。

一个考虑因素是考虑用户名的构成 - 可猜测吗？它们可以被列举吗？

我正在使用一个支持Outlook Web Access / Intranet服务，某些应用程序的员工门户网站进行外部应用笔测试。很容易列举用户（网站上的Exec / Managament团队，以及Google，Facebook，LinkedIn等）。一旦你获得了用户名登录的格式（firstname然后将姓氏作为单个字符串输入），我就有能力将100个用户关闭，因为他们的3次罢工和政策。

Answer 5

本文中的答案优先考虑以数据库为中心的解决方案，因为它们提供了一种记录结构，使审计和锁定逻辑变得方便。

虽然这里的答案解决了对个人用户的猜测攻击，但这种方法的一个主要问题是它使系统对Denial of Service攻击开放。来自世界的任何请求都应该不来触发数据库工作。

应该在req / res周期的早期实现一个替代（或附加）安全层，以保护应用程序和数据库不会执行昂贵且不必要的锁定操作。

Express-Brute是一个很好的例子，利用Redis缓存来过滤掉恶意请求，同时允许诚实的请求。

Answer 6

您知道哪个用户ID被击中，保留一个标志，当它达到阈值时，只需停止接受该用户的任何内容。但这意味着您为每个用户存储了额外的数据值。

  

我喜欢尝试之间指数级增长的概念，[...]

实际上，在连续尝试之间实际上可能存在随机延迟，而不是使用指数增加的时间。

也许如果您解释一下您使用的技术，这里的人们将能够提供更具体的示例。

Answer 7

存储信息服务器端。这样你就可以防御分布式攻击（来自多台机器）。

Answer 8

您可能会说阻止登录一段时间，例如，例如，在3次失败尝试后10分钟。指数增加的时间对我来说听起来不错。是的，将信息存储在服务器端会话或数据库中。数据库更好。没有cookie业务，因为它很容易被用户操纵。

您可能还希望针对客户端IP地址映射此类尝试，因为当其他人尝试通过失败尝试猜测有效用户的密码时，有效用户很可能会收到阻止的消息。