防止登录请求泛滥的简单方法？
如果我的网站使用 POST 表单进行登录，有什么快速、简单的方法可以防止恶意客户端向我的 Web 服务器发送大量 POST 请求，试图暴力破解我的用户帐户？
PHP/MySQL/Apache。
If my website uses a POST form for login, what is a quick and easy way to prevent a rogue client from flooding my web server with POST requests trying to brute force crack my user accounts?
PHP/MySQL/Apache.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
防止暴力破解比乍看起来要棘手。解决方案是组合控制——单一控制无法满足要求。请记住目标：您希望减缓暴力攻击的速度，使其要么无效，要么您可以检测到它并采取行动。第二种选择通常比第一种更有效。
您可以使用验证码（这是目前流行的技术），但验证码通常可以自动读取，当计算机无法读取验证码时，可以通过支付低工资工人或使用验证码来获得人口农场保护“免费”色情内容（两种技术都已使用）。
其他人关于在表单中使用秘密值的建议并没有真正的帮助；攻击者只需解析 HTML 即可找到秘密值，并将其包含在他们的帖子中。这很容易自动化，所以这并不是一个很好的防御。哦，如果结果证明该值很容易预测（使用较差或损坏的 PRNG 或坏种子），那么您又陷入困境了。
跟踪 IP 地址是可以的，但前提是您不支持 NAT。使用 NAT，有效用户将看起来是重复的。请记住，攻击者可以冒充其他系统；单个攻击系统可以使用其他 IP 地址，甚至拦截到该系统的流量（ARP 中毒是一种很好的机制）。
您可以在给定时间段内使用最大失败超时次数（例如 1 小时内 3 次）。这会减慢攻击者的速度，但不一定能阻止他们。您可能会包含自动解锁，但您需要做一些数学计算，并确保解锁时间确实有用。
指数退避是另一种有用的机制。这可能会将会话（攻击者不必返回到服务器）绑定到 IP 地址（与 NAT 中断）或帐户（不考虑跨多个帐户的暴力破解） 。
为了使其他防御措施发挥作用，您必须拥有强密码。如果您的密码很容易被猜到（它们在字典中吗？它们很短吗？它们很复杂吗？），攻击就会成功。实现最低密码强度要求和“非法密码”字典（与该字典的常见字符替换相结合）是一个好主意。或者，您可以使用 OATH、证书登录或硬件令牌（如 RSA 的 SecurID）等系统。
我认为是伯特·卡利斯基讨论了客户的难题。基本上，你给客户端一个对服务器来说很容易但对客户端来说很困难的挑战；客户端通过浪费自己的资源来试图解决这个难题来自我解决。这里的困难在于确定谜题的正确复杂性。例如，它可能需要对一个大数进行因式分解。无论它是什么，您都必须假设最有效的算法，并且您必须能够处理不同机器上不同浏览器的不同性能（可能很慢），同时减慢浏览器外部的自动攻击（可能比你的 JavaScript）。我是否提到过您必须用 JavaScript 实现解决方案？
但您仍然受到跨多个帐户的攻击的困扰。我不知道有任何公开使用的控件可以很好地解决此问题，除非您可以跟踪 IP 地址。
然后，您需要保护用户名。不知道用户名的攻击者（需要一个不指示用户名何时有效的系统）将必须学习用户名和密码，而不是轻松确认用户名，然后只攻击密码。
并且您需要小心错误消息和服务器计时也不会泄露有效密码。
当您处理错误消息时，请确保密码恢复机制不会泄露任何信息。即使在其他方面良好的系统中，密码恢复也会毁掉整个事情。
但是，尽管如此，攻击最终取决于服务器的性能。您可能只是实现一个非常慢的身份验证机制（对于有效和无效的身份验证都必须很慢）。在线攻击的速度保证不会超过服务器处理请求的速度。
然后，您需要检测暴力攻击，因此您的系统需要良好的审计跟踪。但您需要小心，不要记录太多日志消息，否则您将通过填满磁盘空间来开辟一种简单的方法来管理服务器。像 syslog 的“上一条消息已被接收 1000 次”这样的消息就很好了。
一旦你完成了设计工作，并且当你完成了实施工作后，你将需要检查整个系统以及系统的所有功能，在给定当前设置和服务器性能的情况下对其进行数学建模，并确定攻击者暴力破解 (a) 单个帐户和 (b) 任何帐户（跨帐户暴力破解以避免特定于帐户的控制）所需的平均时间。
Preventing brute force cracking is trickier than it may at first seem. The solution will be to combine controls - one single control will not cut the mustard. And remember the goal: you want to slow down a brute force attack to the point where it will either be ineffective, or you can detect it and take action. The second option is generally more effective than than first.
You could use a captcha (this is currently a popular technique) but captchas can often be automatically read, and when they can't be read by a computer, farms of people can be be obtained by paying low waged workers or by using the captcha to protect "free" porn (both techniques have been used).
The advice of others to use a secret value in the form won't really help; an attacker simply has to parse the HTML to find the secret value, and include it in their post. This is pretty simple to automate, so it's not really a good defense. Oh, and if the value turns out to be easily predictable (using a poor or broken PRNG or a bad seed) you're up the creek, again.
Tracking the IP address is okay, but only if you don't support NAT. With NAT, valid users will appear to be duplicates. And remember that attackers can impersonate other systems; a single attack system can use other IP addresses, and even intercept the traffic to that system (ARP poisoning is one good mechanism for this).
You could use a max number of failed timeouts in a given period of time (like 3 within 1 hour). This slows the attacker down, but doesn't necessarily stop them. You might include an automated unlock, but you'll need to do some math, and make sure that the unlock time is actually useful.
Exponential backoff is another useful mechanism. This might be possible to tie to a session (which the attacker doesn't have to return to the server) to the IP address (With breaks with NAT) or to the account (which doesn't account for brute forcing across multiple accounts).
For the other defenses to be useful, you have to have strong passwords. If your passwords are easy to guess (are they in a dictionary? are they short? are they complex?) the attack will succeed. It's a good idea to implement minimum password strength requirements, and an "illegal passwords" dictionary (combined with common character substitutions for that dictionary). Alternatively, you might use a system like OATH, certificate login, or hardware tokens (like RSA's SecurID).
I think it was Burt Kaliski who discussed client puzzles. Basically, you give the client a challenge that's easy for the server, but difficult for the client; the client DoSes itself by wasting its own resources trying to solve the puzzle. The difficulty, here, would be in determining the right complexity for the puzzle. It might, for example, be factoring a large number. Whatever it is, you'd have to assume the most efficient possible algorithm, and you'd have to be able to handle different performance of different browsers on different machines (potentially slow) while slowing down automated attacks outside of browsers (potentially faster than your javascript). Did I mention that you'd have to implement a solution in JavaScript?
But you're still stuck with an attack that works across multiple accounts. I'm not aware of any publicly used controls that work well against this, unless you can track IP addresses.
Then, you'll want to protect usernames. An attacker who doesn't know usernames (requiring a system that doesn't indicate when usernames are valid) will have to learn both the username and the password, instead of easily confirming a username, then just attacking passwords.
And you'll need to be careful that error messages, and server timing don't give away (in)valid passwords, either.
And when you deal with error messages, make sure that password recovery mechanisms don't give anything away. Even in otherwise good systems, password recovery can blow the whole thing.
But, all that said, the attack is ultimately dependant upon the server's performance. You might simply implement a very slow mechanism for authentication (has to be slow for both valid and invalid authns). An online attack is guaranteed to go no faster than the server can process requests.
Then, you need to detect brute force attacks, so your system needs a good audit trail. But you'll need to be careful not to log too many log messages or you'll open up an easy way to dos the server by filling up disk space. Something like syslog's "the previous message has been received 1000 times" message would be good.
Once you're all done designing things, and again when you're done implementing things, you'll want to examine the whole system, and all features of the system, mathematically model it given the current settings and the server's performance and determine the average amount of time it would take an attacker to brute force (a) a single account, and (b) any account (brute forcing across accounts to avoid account-specific controls).
一种方法是跟踪每个请求的 IP 地址（或者甚至是 IP 地址的前 3 个八位字节），并增加大量时间来响应（甚至丢弃）来自具有更多请求的 IP 的请求。过去 y 分钟内的请求数超过 x 个。
这对于分布式攻击无效（或不太有效），但对于相对简单的实现来说，效果很好。
为了获得更强有力的保护，人们还可以通过在一段时间内系统性地拒绝访问此类 IP，将违规 IP（IP，或者 IP 的前 3 个八位字节，在过去 2 分钟或更短的时间内提交了 6 次以上的错误尝试）列入黑名单。说15分钟。
One approach is to keep track of the IP address (or even of the first 3 octets of the IP Address) of each request and to add a significant time in responding to (or even to drop) the requests coming from IPs that have had more than x requests in the last y minutes.
This is ineffective (or less effective) against distributed attacks, but otherwise work quite well, for a relatively simple implentation.
For a stronger proptection, one can also blacklist offending IPs (IPs, or again first 3 octets of IP, which have submitted more than say 6 bad attempts in the last 2 minutes or less) by systematically denying access to such IP for a period of say 15 minutes.
好吧，如果您知道登录尝试源的 IP，您可以允许登录尝试 5 次，然后让该 IP 等待 5 分钟的“冷静”期。如果您认为 5 分钟太短，请将其提高，直到更合适（可以长达 24 小时，如果您认为有必要，则可以更长）。如果僵尸网络中有数十个协调节点，这可能不太有效。
Well, if you know the IP of the source of the login attempt, you could allow it 5 attempts, then make that IP wait through a 5 minute "cool-off" period. If you think 5 minutes is too short, raise it until it's something more suitable (could go as high as 24 hours, or more if you think it's necessary). This might not work as well if they have dozens of coordinated nodes in a botnet.