14

I have set up my db to log every failed login attempt. I thought I would multiply the number of failed attempts with 0.05 seconds or something. Something like:

            time_nanosleep(0, (50000000 * $failed_attempts ) );

More attempts a hacker uses to guess a password, more time does it take to check every time. After checking a 100 passords he must wait 5 sec between each try.

Is this a good way to stop bruteforcing? I identify the users by IP. So I guess you can bruteforce the application by using multiple proxy servers or something, but besides that, I think is a good idea. What do you guys think?

ganjan
  • 7,356
  • 24
  • 82
  • 133

8 Answers8

9

What about something like:

time_nanosleep(0, (10000000000 * (log($failed_attempts)^10)) );

This will give you an exponentially increasing attempt window.

Industrial
  • 41,400
  • 69
  • 194
  • 289
Greg Buehler
  • 3,897
  • 3
  • 32
  • 39
  • You should use an arbitrary value and not increase the time exponentially. An attacker will ignore the extra time as he realizes that you are increasing it for each failed attempt. This will end up costing your server some resources and it does not provide any other security benefit. – MaxVerro Jul 04 '18 at 11:03
5

The first issue I see is that you are dealing with a bot that doesn't care if there is a delay between responses. Unless you do something to limit this you are using up system resources with potentially very long delays. Just ban the IP after 5 failed attempts. It can be a temporary ban if you are worried about banning a real user.

Brent Friar
  • 10,588
  • 2
  • 20
  • 31
  • 3
    I'm not sure exactly what Friar has in mind, but this leads me to an interesting thought. Instead of doing a sleep, why not reject the user for an exponentially growing period of time? That is, after one failure, any further login attempts from that IP within, say, 1 second are rejected. Next failure 2 seconds. Etc. For a human user who's mistyped the password, he probably won't even notice: he'll take more than a couple of seconds to check his password and retype. But to the bot, he'll get failure's that he probably doesn't know how to interpret. – Jay Jan 27 '11 at 17:53
3

It shouldn't be your entire strategy against bruteforcing, but it's an excellent component for that strategy and IMO should pretty much always be used.

chaos
  • 122,029
  • 33
  • 303
  • 309
  • I don't see much benefit -- what's going on is going to become clear to the cracker as the average delay escalates, regardless -- but I don't see any harm either if it appeals to you. – chaos Jan 27 '11 at 17:11
  • 1
    @chaos: So what? The point isn't to surprise the attacker, just to slow down his attack. We build walls around a castle to make it hard for attackers to get in. The fact that the attacker sees the walls and realizes that they are there to keep him out doesn't make them less effective. – Jay Jan 27 '11 at 17:49
  • You seem to be responding to points I'm not making. My comment was in response to akond. – chaos Jan 27 '11 at 18:16
3

Limit retries by IP and use a CAPTCHA. Don't overload your server, think KISS.

Chinmoy
  • 1,750
  • 2
  • 21
  • 45
3

You should try not to use Sleep() because it uses CPU cycles, and if you have a brute force attack from 10,000 IP addresses you will fork 10,000 sleep() child processes or threads, this will cause lots of load on your server.

Instead try to block the IP address using PHP. Something like this.

function block_ip($ip) {
    $deny = array("$ip");
    if (in_array ($_SERVER['REMOTE_ADDR'], $deny)) {
        header("HTTP/1.1 403 Forbidden");
        exit();
    }
}
Community
  • 1
  • 1
jackson
  • 31
  • 1
1

You might want to increase that time exponentially instead of just linearly; or make it fixed, e.g. deny for an hour after 5 failed attempts.

ChrisW
  • 54,973
  • 13
  • 116
  • 224
0

I know I've seen this done somewhere, though I forget where. The example I saw, they doubled the time delay with each failed attempt. If you started with, say, .1 seconds, a normal user who might mistype his password once or twice gets up to a delay of .4 seconds. They won't even notice. But somebody who tries a brute force attack his quickly going to get delays in the minutes or hours.

I guess for a web app there might be an issue of launching a denial-of-service attack on yourself. It all depends on how the system handles the time delays.

Jay
  • 26,876
  • 10
  • 61
  • 112
0

Bots do not really care about your delay, whether it is exponential or logarithmic or anything. Any delay you use can be overcome by polling. So, do not think delay. Think about limiting the number of attempts and use Google reCAPTCHA. It uses public-private key encryption. Works for eliminating most bots and is harder to crack.

Chinmoy
  • 1,750
  • 2
  • 21
  • 45