限制（和记录）登录尝试的最佳方法
显然，某种限制登录尝试的机制是安全必需的。 虽然我喜欢尝试之间的时间呈指数增长的概念，但我不确定存储信息的内容。 我也对替代解决方案感兴趣，最好不包括验证码。
我猜测 cookie 由于阻止 cookie 或自动清除它们而无法工作，但是会话会工作吗？ 还是必须将其存储在数据库中？ 不知道可以/正在使用哪些方法，所以我根本不知道什么是实用的。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
使用用户表“failed_login_attempts”和“failed_login_time”中的一些列。 第一个在每次登录失败时递增，并在成功登录时重置。 第二个允许您将当前时间与上次失败时间进行比较。
您的代码可以使用数据库中的此数据来确定锁定用户等待的时间、允许登录之间的时间等
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
假设谷歌已经完成了必要的可用性测试（这不是一个不公平的假设）并决定使用 captchas ，我建议与他们合作。
当我是一个真正的用户并且忘记了我的密码时，增加超时令人沮丧（有很多网站及其相关密码，这种情况经常发生，尤其是对我来说）
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)
恕我直言，在数据库中存储尝试是最好的解决方案，因为它为您提供了安全漏洞尝试的审核记录。 根据您的应用程序，这可能是也可能不是法律要求。
通过记录所有不良尝试，您还可以收集更高级别的信息，例如请求是否来自一个 IP 地址（即某人/事物正在尝试暴力攻击），以便您可以阻止该 IP 地址。 这可能是非常有用的信息。
一旦您确定了阈值，为什么不强迫他们请求将电子邮件发送到他们的电子邮件地址（即类似于“我忘记了密码”），或者您可以采用验证码方法。
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.
本文中的答案优先考虑以数据库为中心的解决方案，因为它们提供了一种使审核和锁定逻辑变得方便的记录结构。
虽然这里的答案解决了对个人用户的猜测攻击，但这种方法的一个主要问题是它使系统对 拒绝服务攻击。 来自世界各地的任何请求都不应触发数据库工作。
应在 req/res 周期的早期实施替代（或附加）安全层，以保护应用程序和数据库免于执行成本高昂且不必要的锁定操作。
Express-Brute 是一个很好的例子，它利用 Redis 缓存过滤掉恶意请求，同时允许诚实的请求那些。
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 Denial of Service 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.
Express-Brute is an excellent example that utilizes Redis caching to filter out malicious requests while allowing honest ones.
您知道哪个用户 ID 被命中，保留一个标志，当它达到阈值时，只需停止接受该用户的任何内容。 但这意味着您为每个用户存储额外的数据值。
您实际上可以在连续尝试之间设置随机滞后，而不是使用指数增加的时间。
也许如果您解释一下您正在使用什么技术，这里的人们将能够提供更具体的示例来提供帮助。
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.
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.
锁定政策一切都很好，但需要平衡。
一个考虑因素是考虑用户名的构造——可以猜测吗？ 它们可以一一列举吗？
我正在为一家网络公司进行外部应用程序笔测试，该公司的员工门户为 Outlook Web Access/Intranet 服务和某些应用程序提供服务。 枚举用户很容易（网站本身的执行/管理团队，以及通过 Google、Facebook、LinkedIn 等）。 一旦你获得了用户名登录的格式（名字然后姓氏作为单个字符串输入），我就有能力将 100 个用户拒之门外，因为他们的 3 次罢工和退出政策。
Lock out Policy is all well and good but there is a balance.
One consideration is to think about the construction 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 /Management 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.
将信息存储在服务器端。 这还允许您防御分布式攻击（来自多台计算机）。
Store the information server-side. This would allow you to also defend against distributed attacks (coming from multiple machines).
您可能会说阻止登录一段时间，例如 3 次失败尝试后 10 分钟。 指数增加时间对我来说听起来不错。 是的，将信息存储在服务器端会话或数据库中。 数据库比较好。 没有cookies业务，因为它很容易被用户操纵。
您可能还希望将此类尝试映射到客户端 IP 地址，因为当其他人试图通过失败的尝试猜测有效用户的密码时，有效用户很可能会收到被阻止的消息。
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.