PHP 中限制用户登录尝试
我见过一些网络应用程序对用户登录尝试有限制。
这是出于安全需要吗？如果是，为什么？
例如：您尝试登录失败了 3 次，请在 10 分钟后重试！！
I've seen web apps with limitations for user login attempts.
Is it a security necessity and, if so, why?
For example: you had three failed login attempts, let's try again in 10 minutes!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我曾经看到过一种创造性的方法......
对于每次失败的登录尝试，锁定时间都会增加......呈指数级增长。
从理论上讲，它会让用户犯一两个错误，但一旦它看起来成为“黑客”尝试，黑客就会被锁定越来越长的时间。
我自己还没有使用过这个，但从概念上讲我非常喜欢这个想法。 当然，成功登录后，计数器会重置。
I saw a creative approach to this once...
For each login attempt, that fails, the lockout time increases... exponentially.
In theory, it lets user make a mistake or two, but as soon as it appears to become a "hacking" attempt, the hacker gets locked out for longer and longer time periods.
I haven't used this myself (yet), but conceptually I quite like the idea. Of course on successful login, the counter is reset.
澄清 这是对其他答案的补充。 使用良好的验证码以及使用会话的反暴力破解机制。
提问者将此标记为已接受，假设验证码无法被机器读取（她几乎是对的），因此它得到了负分，因为人们认为这不是一个完整的答案& 他们是对的。
此外，使用良好实施的验证码可能是增强应用程序安全性以抵御暴力攻击的另一种方法。 各种各样的验证码提供商 免费提供，如果您赶时间，让我们尝试一下简单的方法。 另请注意，这里有人们说“哦，不！这个验证码不够安全，但有时它们是对的！”。
Clarification This is a completion to the other answers. Using a good implemented captcha alongside an anti-bruteforce mechanism using sessions for example.
The questioner marked this as accepted assuming that captchas are unreadable by machines (she's almost right) and so it's getting negative points, because people think it's not a complete answer & they're right.
Also using a good implemented CAPTCHA could be an alternative way to enpower your application security against brute-force attacks. there's a wide variety of captcha providers available for free, let's try the easy way if you're in a hurry. Also please consider that there's people outta here saying that "oh, no! this captcha thing is not secure enough and they're right sometimes!".
限制在网站上进行的尝试次数是为了防止暴力（自动）攻击您的网站。 如果您不限制这些尝试，黑客可以设置一个脚本来不断猜测密码，直到找到密码，这可能会影响您的 Web 服务器的可用性。
通常，您可能希望在 3 次尝试后让用户超时（如您提到的 10 分钟），并在连续 6 或 9 次重复尝试后将其锁定，迫使用户与您联系以解锁其帐户。 之所以这样做，是因为有人可以修改他们的脚本来调整您的超时。
The limiting of how many attempts to be made on a website are to prevent brute force (automated) attacks your site. If you don't limit these attempts, a hacker can set up a script to keep guessing passwords until it finds one, and this may impact the availability of your web server.
Typically, you may want to time the user out (10 minutes as you mentioned) after 3 attempts, and lock them out after 6 or 9 consecutive repeated attempts, forcing the user to contact you in order to unlock their account. This is put into place because someone can modify their scripts to adjust your timeout.
如果用户可以设置自己的密码，某些机器人/孩子将尝试使用常用密码列表登录并成功。 如果他们不认识任何用户，他们会尝试常见的名称，如 admin、simon、rico 等。
仅在会话中标记用户并没有帮助，因为他们可以删除末尾的 cookie 或查询参数。 您需要统计 IP 和登录名的登录尝试失败次数。 也许对 IP 更加宽容，因为它可以在许多用户之间共享。
If users can set their own passwords, some bot/kid will try to log in with a list of common passwords, and succeed. And if they don't know any users, they will try common names like admin, simon, rico, etc.
It doesn't help to just flag the user in session, as they can just remove the cookie or query param on their end. You need to have a count of failed login attempts for both IP and login name. Maybe be more forgiving for the IP as it can be shared among many users.
对于我自己的项目，我编写了一个通用的“洪水控制”库来处理此类事情。
它允许我指定在 X 时间内可以进行多少次尝试。 它允许在短时间内进行一定数量的“宽限”尝试，因此只有真正不寻常的行为才会被捕获。
我在数据库中记录了一些内容：
对于每次尝试，我都会查询部分 IP 地址和操作，如果之前的尝试是在某个时间窗口内进行的，那么我会增加该尝试的尝试计数器。 如果尝试计数器超过允许的宽限尝试次数，则我检查最后一次尝试是否在现在的 X 秒内，如果是，则返回 false - 因此该操作将被阻止（并且用户将被告知在尝试之前等待 X 秒）再次）。 如果尝试计数器低于宽限尝试次数，则我返回 true 并让它滑动。
如果稍后有相同 IP 的人过来，则不会获取之前的尝试计数，因为它已经是很久以前的事了。
For my own projects I wrote a generalized 'floodcontrol' library which handles this sort of thing.
It allows me to specify how many attempts may be made in X amount of time. It allows for a certain number of 'grace' attempts in a short time, so that only really unusual behaviour will be caught.
I record in the database a few things:
For each attempt made I query against the partial IP address and the action, and if a previous attempt was made within a certain window of time then I increment the attempt counter for that attempt. If the attempt counter exceeds the number of grace attempts allowed then I check whether the last attempt was within X seconds of now and if so, return false - therefore the action will be blocked (and the user will be told to wait X seconds before trying again). If the attempt counter is below the number of grace attempts then I return true and let it slide.
If a person with the same IP comes by later, then the previous attempt count won't be fetched, because it will be too long ago.
是的，有必要保护帐户免受复杂的暴力攻击（例如使用机器人和字典文件），甚至有人试图猜测帐户的密码。
Yes, it's necessary to protect accounts from sophisticated brute force attacks - as in, using bots and dictionary files - down to someone just trying to guess the password of the account.
正确登录后重置失败的尝试几乎使整个系统变得毫无价值。
然后，任何注册用户都可以对其他人的帐户和密码进行三次猜测，然后使用自己的帐户和密码登录以重置计数器，然后重复 - 这也可以自动化。 例如，普通注册用户可以暴力破解管理员密码。
重置需要由管理员完成，而不是简单地登录成功。
Resetting the failed attempts after a correct login almost makes the whole system worthless.
Any registered user could then do three guesses on someone else's account and password, then log in with their own to reset the counter, and repeat — that can be automated, too. So a normal registered user can brute force admin passwords, for example.
The reset needs to be done by the admin, not by simply logging in successfully.
我认为在数据库中放置“尝试失败”计数器将是最安全、最简单的方法。 这样用户就无法绕过它（通过禁用 cookie）。 当然，登录成功后会重置。
您可以按 IP 和/或用户名进行计数。 IP 的优点是您可以阻止一个人尝试破解多个帐户。 如果您按用户名进行计数，则可以阻止使用服务器场的人员，并且不会意外限制同一网络上的人员。
I reckon putting a 'failed attempts' counter in the DB would be the safest and easiest way to go. That way the user can't bypass it (by disabling cookies). Reset on successful login of course.
You can count by IP and/or by username. Advantage of IP is that you can block one person trying to hack multiple accounts. If you count by username you can block people using a server farm and won't accidentally throttle people on the same network.