22

(I just asked this question on "cryptography SE" and was suggested to ask it here instead)

EDIT I just realized my question is mostly a dupe of: Prevent denial of service attacks against slow hashing functions?

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?

Community
  • 1
Cedric Martin
  • 587
  • 1
  • 6
  • 14
  • 1
    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
  • 2
    @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 Martin Sep 27 '12 at 17:30

3 Answers3

17

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.
Brendan Long
  • 2,898
  • 1
  • 19
  • 27
  • 2
    Point 4 is generally called a [proof of work system](http://en.wikipedia.org/wiki/Proof-of-work_system). Also a requirement of javascript/client-side scripting is often a benefit. – dr jimbob Sep 27 '12 at 21:55
  • @drjimbob Thanks, I was trying to remember what it was called. – Brendan Long Sep 27 '12 at 21:55
  • While PoW is an interesting way to prevent DoS, be aware that the required time to solve it may vary depending on users' computing resources. Think of a user trying to sign in with Raspberry Pi Zero. – Константин Ван Feb 04 '19 at 08:21
  • The last point, attackers can also inflate your email bill. – iBug Dec 13 '20 at 07:01
6

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 server into doing lots of computation.

DoS is a risk with any service. The more processing it requires, the more important rate limiting is whether we're talking about hashing passwords or making database queries.

When considering how many rounds, think about how the tradeoff between handling authentication load and keeping systems available. See another answer of mine referencing determining how many bcrypt rounds to use.

Community
  • 1
Jeff Ferland
  • 38,170
  • 9
  • 94
  • 172
1

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.

Bradley Kreider
  • 6,182
  • 2
  • 24
  • 36