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: 
You are right that **using PBKDF2 does not protect against brute-force attacks on web application login pages**. Credentials submitted by users and attackers travel unchanged until the server, where PBKDF2 is then computed. PBKDF2 is therefore only meaningful for offline attacks which have direct access to the correct hashes.

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

The same protection could be achieved more effectively and efficiently by implementing in the front-end application logic one or more among CAPTCHA, [account lockout and/or password throttling](https://security.stackexchange.com/questions/74211/what-is-the-difference-between-login-throttling-and-temporary-account-lockout#74214). 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).
If you are [hashing and storing passwords correctly](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) (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.