限制(和记录)登录尝试的最佳方法

Question

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

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

Answer 1

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

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

另外,我发现,你应该存储无效用户名的失败登录尝试.如果您只锁定了对有效用户名的失败尝试,那么您将揭示哪些用户名是有效的,这是禁止的. (15认同)
我喜欢根据两个标准存储失败：如果使用了有效的用户名，则计算用户名和 IP 的失败，否则只计算 IP 的失败。如果特定帐户受到攻击，那么它将独立于特定 IP 锁定该帐户，并且在此过程中任何单个滥用 IP 都会被整个站点锁定。为锁存储明确的到期时间并在每次尝试时更新锁到期时间也很重要。 (2认同)

Answer 2

假设谷歌已经做了必要的可用性测试(不是不公平的假设)并且决定使用验证码,我建议一起使用它们.

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

Answer 3

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

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

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

Answer 4

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

虽然这里的答案解决了针对个人用户的猜测攻击，但这种方法的一个主要问题是它使系统容易受到拒绝服务攻击。任何和来自世界的每一个请求应该不会触发数据库工作。

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

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