10 request/minute for brute force attack and ddos?

Question

If I save the time of first logging attempt and if the 10th attempt is made in less than 1 minute and I ban the IP address would that be enough to stop brute force attack and ddos? In real life example will it be possible for a user to enter the wrong address more than 10 times in a minute?

EDIT: maybe I didn't put the question in right way, would blocking the user/ip after 10 req/m make the system much more secure, than standard block after 10 wrong attempts?

For making a thing secure **Nothing** would be enough. You should think how much is it important. (how much your site is important and would have enemies). — ncm, Jun 03 '13 at 10:16
banning Ip address is not a good idea. You can ban the login details. — pinku, Jun 03 '13 at 10:19
@CORRUPT you think not about stopping the brute force attack or that a user could go wrong 10 times/minute? — lesandru, Jun 03 '13 at 10:21
Try http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication/477578#477578 part vi and vii have good tips — rlb, Jun 03 '13 at 10:22
@pinku I do block the user for 10-15 minutes, but I do a check of first IP attempt and last IP attempt against of last login attempt and if none of these match I block the IP — lesandru, Jun 03 '13 at 10:24
What if a user has a bad connection and clicks "Login" button repeatedly 10 times a minute because he's not patient? — Voitcus, Jun 03 '13 at 10:29
@lesandru It was about user real user attempts. Except autosaved password, there is no chance for good / average passwords or addresses. — BlitZ, Jun 03 '13 at 10:32

score 1 · Answer 1 · answered Jun 03 '13 at 10:51

I think that the detecting method is quite correct. If a user tries to log in 10 times a minute this is something wrong here.

But you need to check if:

the user is impatient so clicks ten times just to "make the loading faster". It's ok if you disable login button with JavaScript but the user can have JS disabled.
the user clicks "refresh" on the perform-login page, so that the browser resends the post data. This is possible even if redirecting him, because he's got low connection speed. So this could be treated by you as an attack.
the user has auto-completed form with wrong password stored. He clicks, so there is error, so he does it again, and again, and again.

In my opinion this is no counter-measure if he's trying to make a DoS attack, because it doesn't matter what query he makes, because he just wants to halt your server. And, moreover, he will try to do this from many computers with different IPs so you can't easily block them.

I think blocking an IP is no protection and makes the user sure that you have something to hide. You are able to block him this way, so he'll start another way, the one you had not even thought of. I think -- as the other comments say -- you should temporarily block the user (you can log the IP, why not?), but showing him something like "Internal server/database error, please wait".

All the major sites of largest worldwide companies do not block anybody.

And finally answering to your question: yes, this method will make your system more secure in short term, but user should never know he's been blocked.

thanks @Voitcus I will take out the IP block idea, but the way I did it before the IP, if the user is blocked he gets the invalid username/password even if he does 1000 wrong attempts, but once he put the right password he gets a message that his account has been blocked for too many attempts with an option to unblock it, would that be good for the user and for a possible attack? — lesandru, Jun 03 '13 at 11:08
I think it's security ok, but this can be unfair in the user-experience point of view. If someone uses my login to break into your site, why should I be forced to change password or something? It's not my fault and I am not interested in your security holes. Somebody could use this way to block other users. I think that disallowing the user to log in for 2 or 5 or 10 minutes is enough, but for some "technical reasons". — Voitcus, Jun 03 '13 at 11:31

score 0 · Answer 2 · answered Oct 15 '14 at 23:27

I made a class that takes care of brute force attack protection in PHP.

https://github.com/ejfrancis/BruteForceBlocker

it logs all failed logins site-wide in a db table, and if the number of failed logins in the last 10 minutes (or whatever time frame you choose) is over a set limit (also chosen by you), it enforces a time delay and/or a captcha requirement before logging in again.

example:

//build throttle settings array. (# recent failed logins => response).

$throttle_settings = [
    50 => 2,            //delay in seconds
    150 => 4,           //delay in seconds
    300 => 'captcha'    //captcha 
];

$BFBresponse = BruteForceBlocker::getLoginStatus($throttle_settings);

//$throttle_settings is an optional parameter. if it's not included,the default settings array in BruteForceBlocker.php will be used

switch ($BFBresponse['status']){
case 'safe':
    //safe to login
    break;
case 'error':
    //error occured. get message
    $error_message = $BFBresponse['message'];
    break;
case 'delay':
    //time delay required before next login
    $remaining_delay_in_seconds = $BFBresponse['message'];
    break;
case 'captcha':
    //captcha required
    break;
}

10 request/minute for brute force attack and ddos?

2 Answers2