Is using PBKDF2 good protection against brute-force attacks on web application login pages?

Question

We've recently had a penetration test for one of our applications.

The Penetration Testing company identified that our application lacks protections against brute-force attacks on the login page.

Ref: https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

We've been recommended to implement a captcha to disrupt brute-force attacks on the login page which I believe works well with the context and users of the application.

One of our engineers is insisting that we have enough protection against these attacks because we're using PBKDF2 as our hashing algorithm.

I understand that PBKDF2 slows down hashing computations and prevents offline cracking and in turn also slows down login brute-force attacks, but I fail to see how it removes the need for anti-automation prevention mechanisms? I don't see why we should even allow someone to try hundreds of thousands user/password combinations on the login page in the first place. It does not seem to address the identified problem.

The security company has provided a similar argument, but I'm having trouble convincing my Engineer colleague.

Question: Is using PBKDF2 good protection against brute-force attacks on web application login pages?

Answer 1

You are right that using PBKDF2 does not protect against brute-force attacks on web application login pages. Credentials submitted by users (and by attackers) travel unchanged through the TLS tunnel to the server, where PBKDF2 is then computed. PBKDF2 is only meaningful for offline attacks having direct access to server hashes.

The only scenario where PBKDF2 is loosely related to brute-force attacks on web application pages is when login pages respond faster than the server computes PBKDF2 hashes: in that case a parallelized brute-force attack would be somewhat slowed down. However it would also require a lot of unnecessary computing power and it might prevent other users from logging in.

Brute force attacks against web application pages could instead be mitigated effectively and efficiently by implementing in the front-end application logic (and by enforcing through back-end logic) one or more among CAPTCHA, account lockout and/or password throttling. These controls should ideally be weighed based on client IP address history and reputation (e.g. a Tor exit node having already failed multiple logons should be heavily penalized).

Answer 2

If you are hashing and storing passwords correctly (regardless of whether you use PBKDF2 as your hashing function, or some other hashing funcion), then your server is doing the heavy lifting for each login attempt made at your site.

Perhaps your engineer has a slight misunderstanding in the premise of how password hashing works, and he thinks that password hashing somehow forces the client to expend computational power during a login attempt. But, that's not the case. Password hashing happens on the server side during a login attempt, and a large number of login attempts continuously could potentially DOS your server.

Answer 3

If your password hashing function is slow enough to prevent brute-forcing your logins, it's also so slow that it can trivially be abused to cause denial-of-service (prevent anybody from logging in, or getting the login server to do anything else either). This is an important balancing act in password hashing functions: you need to make them slow (to prevent offline cracking), but not so slow that it annoys users or that a lot of requests in parallel will overload your server.

Besides, you're quite right; there's no reason to let somebody's script sit there and try passwords all year long, even if they can only try a few per second due to the password hashing. Also, normally they'd parallelize the attack, so each worker could only try one at a time, but overall the attacker could try as many in parallel as they want (well, as your server will permit). You absolutely need a mechanism to block this sort of brute-force attack. CAPTCHAs are one good option. IP-based blocks can DoS legitimate users without meaningfully impairing attackers, and so can account lockouts (unless the attacker is only trying to get into one specific account, but usually they're happy to try others until the lockout ends).

---

Also, get a better password hashing function. PBKDF2 has almost no memory cost, so it is trivial to parallelize. It'll still take longer than a plain hash, but not by nearly as much as if you use a high-memory-cost hashing function to prevent attackers from running it in parallel on each core of their GPU (or rather, create a memory I/O bottleneck if they try).