If someone chooses bcrypt isn't the server(s) particularly exposed to a DoS attack that would try to max out the CPU?

If we take, say, a webserver: even if it has a gigantic network bandwith it looks like remotely hammering the server with HTTP POST login requests could give the CPU a hard time.

If the server doesn't rate limit anything it looks like even from a single machine / IP it wouldn't be too hard to force the serve into doing lots of computation.

Is this something to worry about (for example do you need to add some kind of special rate-limiting firewalling specifically taking "remote bcrypt attacks" into account) or am I just being paranoid here?

Any server is vulnerable to DoS, whether they are using bcrypt or not. Do you mean to ask if a server is particularly vulnerable to DoS if it uses bcrypt? Rate-limiting logins can create a self-DoS situation where new valid logins are blocked before they would normally be because you set the threshold artificially low.
–
schroeder♦Sep 27 '12 at 16:49

1

@schroeder: I meant to ask if a server is particularly vulnerable to DoS attacks trying to max out the CPU seen that bcrypt is particularly CPU intensive. I'm concerned because DoS attacks trying to max out the CPU (instead of the bandwith) do definitely exist: late 2011 there was the famous PHP / Java hashmap SNAFU were a few long GET URLs with crafted parameters could take down most PHP and Java servers. I don't agree that every server is vulnerable to a DoS: every server is vulnerable to a DDoS, not a simple DoS. If anyone with an IP can DoS your server you're in big trouble.
–
Cedric MartinSep 27 '12 at 17:30

3 Answers
3

bcrypt is slow, which definitely increases the risk of an easy DoS attack, but there are a number of ways you could rate-limit clients before they get to the bcrypt step:

Keep track of IP addresses and ignore anyone trying to log in too quickly (maybe start out by pausing for certain amount of time before authenticating, then work your way up to a blacklisting IP's).

Put login attempts in a priority queue and set priority based on how many failed login attempts a particular IP address as made recently. This will leave your server under heavy load, but legitimate users should be able to get in.

Add a CAPTCHA. CAPTCHA's are annoying, so only require this if you detect an attack in progress or you get too many attempts from a single IP address.

Make the client's machine do something expensive as part of the login process, like cracking a short hash or finding the prime factors of a small number. This has the advantage that using a different IP won't help, but it would mean JavaScript is required to log in.

Detect when a user is attempting to log in from a new location and send them an email. Don't even bother trying to check the password until the IP address is authenticated. This has the disadvantage that attackers could annoy (and scare) your users if they have a sufficiently large number of IP addresses to work with.

Off the top of my head, I would believe that you'd run out of sockets or ports before using all of the CPU on a modern machine. If you haven't tuned your machine to a low value for time_wait, ports would get exhausted.