blocks|key|1057042|text|假设谷歌已经做了必要的可用性测试(不是一个不公平的假设)，并决定使用验证码，我建议使用它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1057043|当我是一个真正的用户并忘记了我的密码时，增加超时是令人沮丧的(有如此多的网站及其相关的密码经常发生，特别是对我来说)|1057044|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Assuming google has done the necessary usability testing (not an unfair assumption) and decided to use captchas , I'd suggest going along with them.

Increasing timeouts is frustrating when I'm a genuine user and have forgotten my password (with so many websites and their associated passwords that happens a lot , especially to me)

blocks|key|3596907|text|将尝试存储在数据库中是最好的解决方案IMHO，因为它为您提供了安全违规尝试的审计记录。这可能是也可能不是法律要求，具体取决于您的应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3596908|通过记录所有恶意尝试，您还可以收集更高级别的信息，例如，如果请求来自一个IP地址(即某人/某物正在尝试暴力破解攻击)，则您可以阻止该IP地址。这可能是非常有用的信息。|3596909|一旦你确定了一个阈值，为什么不强制他们请求将电子邮件发送到他们的电子邮件地址(例如，类似于“我忘记了我的密码”)，或者你可以使用验证码方法。|3596910|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Storing attempts in the database is the best solution IMHO since it gives you the auditing records of the security breach attempts. Depending on your application this may or may not be a legal requirement. 

By recording all bad attempts you can also gather higher level information, such as if the requests are coming from one IP address (i.e. someone / thing is attempting a brute force attack) so you can block the IP address. This can be VERY usefull information.

Once you have determined a threshold, why not force them to request the email to be sent to their email address (i.e. similar to 'I have forgotten my password'), or you can go for the CAPCHA approach.

blocks|key|1052166|text|你知道哪个userid被击中了，保留一个标志，当它达到一个阈值时，简单地停止接受该用户的任何东西。但这意味着您为每个用户存储了一个额外的数据值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1052167|1052168|我喜欢两次尝试之间的时间呈指数级增长的概念，...|blockquote|1052169|1052170|1052171|与使用指数级增长的时间不同，你可以在连续的尝试之间有一个随机的延迟。|1052172|也许，如果你解释一下你使用的是什么技术，这里的人将能够提供更具体的例子。|1052173|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|P|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|S|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|T|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|M|$]]

You know which userid is being hit, keep a flag and when it reaches a threshold value simply stop accepting anything for that user. But that means you store an extra data value for every user.

<blockquote>
 I like the concept of an exponentially increasing time between attempts, [...]
</blockquote>

Instead of using exponentially increasing time, you could actually have a randomized lag between successive attempts.

Maybe if you explain what technology you are using people here will be able to help with more specific examples.

blocks|key|3596988|text|将信息存储在服务器端。这将允许您防御分布式攻击(来自多台机器)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3596989|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Store the information server-side. This would allow you to also defend against distributed attacks (coming from multiple machines).

blocks|key|3597058|text|使用users表'failed_login_attempts‘和'failed_login_time’中的一些列。第一个参数在每次登录失败时递增，并在成功登录时重置。第二个允许您将当前时间与上次失败的时间进行比较。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3597059|您的代码可以在数据库中使用此数据来确定锁定用户的等待时间、允许的登录间隔时间等。|3597060|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Use some columns in your users table 'failed_login_attempts' and 'failed_login_time'. The first one increments per failed login, and resets on successful login. The second one allows you to compare the current time with the last failed time.

Your code can use this data in the db to determine how long it waits to lock out users, time between allowed logins etc

blocks|key|3597128|text|您可能希望在一段时间内阻止登录，例如，在3次失败尝试后10分钟。成倍增长的时间对我来说听起来不错。是的，将信息存储在服务器端会话或数据库中。数据库更好。没有cookies业务，因为它很容易被用户操纵。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3597129|您可能还希望将此类尝试映射到客户端IP地址，因为有效用户很可能会收到阻止的消息，而其他用户试图通过失败的尝试来猜测有效用户的密码。|3597130|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You may like to say block the login for some time say for example, 10 minutes after 3 failure attempts for example. Exponentially increasing time sounds good to me. And yes, store the information at the server side session or database. Database is better. No cookies business as it is easy to manipulate by the user. 

You may also want to map such attempts against the client IP adrress as it is quite possible that valid user might get a blocked message while someone else is trying to guess valid user's password with failure attempts.

blocks|key|3597407|text|锁定策略是很好的，但也有一个平衡。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3597408|其中一个考虑因素是考虑用户名的构成--可以猜测吗？它们完全可以被枚举吗？|3597409|我在一个网络公司的外部应用程序笔测试中，有一个员工门户网站，为Outlook+Web+Access+/Intranet服务，某些应用程序提供服务。它很容易列举用户(+Exec+/Managament团队在网站上，并通过谷歌，脸书，LinkedIn等)。一旦你得到了用户名登录的格式(名字，然后是姓氏作为一个字符串输入)，我就有能力因为他们的三振出局策略而将100个用户拒之门外。|3597410|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Lock out Policy is all well and good but there is a balance. 

One consideration is to think about the consruction of usernames - guessable? Can they be enumerated at all? 

I was on an External App Pen Test for a dotcom with an Employee Portal that served Outlook Web Access /Intranet Services, certain Apps. It was easy to enumerate users (the Exec /Managament Team on the web site itself, and through the likes of Google, Facebook, LinkedIn etc). Once you got the format of the username logon (firstname then surname entered as a single string) I had the capability to shut 100's of users out due to their 3 strikes and out policy.

blocks|key|379442|text|这篇文章中的答案优先考虑以数据库为中心的解决方案，因为它们提供了一种记录结构，使审计和锁定逻辑变得方便。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|379443|虽然这里的答案解决了针对单个用户的猜测攻击，但这种方法的一个主要问题是它会使系统面临Denial+of+Service攻击。任何来自世界的请求都应该触发数据库工作。|offset|length|379444|应该在请求/资源周期的早期实现替代的(或附加的)安全层，以防止应用程序和数据库执行代价高昂且不必要的锁定操作。|379445|Express-Brute就是一个很好的例子，它利用Redis缓存过滤掉恶意请求，同时允许诚实的请求。|379446|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Denial-of-service_attack|1|https://www.npmjs.com/package/express-brute^0|0|16|H|0|0|0|0|D|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

Answers in this post prioritize database centered solutions because they provide a structure of records that make auditing and lockout logic convenient.

While the answers here address guessing attacks on individual users, a major concern with this approach is that it leaves the system open to <a href="https://en.wikipedia.org/wiki/Denial-of-service_attack" rel="noreferrer">Denial of Service</a> attacks. Any and every request from the world should not trigger database work.

An alternative (or additional) layer of security should be implemented earlier in the req/ res cycle to protect the application and database from performing lock out operations that can be expensive and are unnecessary.

<a href="https://www.npmjs.com/package/express-brute" rel="noreferrer">Express-Brute</a> is an excellent example that utilizes Redis caching to filter out malicious requests while allowing honest ones.

Obviously some sort of mechanism for limiting login attempts is a security requisite. While I like the concept of an exponentially increasing time between attempts, what I'm not sure of storing the information. I'm also interested in alternative solutions, preferrably not including captchas.

I'm guessing a cookie wouldn't work due to blocking cookies or clearing them automatically, but would sessions work? Or does it have to be stored in a database? Being unaware of what methods can/are being used so I simply don't know what's practical.

Best way to limit (and record) login attempts

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

显然，某种限制登录尝试的机制是安全必需的。虽然我喜欢两次尝试之间的时间呈指数级增长的概念，但我不确定是否可以存储信息。我也对其他解决方案感兴趣，最好不要包括验证码。我猜cookie不会工作，因为阻止cookie或自动清除它们，但会话可以工作吗？或者必须将其存储在数据库中？不知道可以/正在使用什么方法，所以我根本不知道什...

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

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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