3

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?

Silvercroft
  • 33
  • 6
  • Haven't you both read the pages `If your web site requires user authentication, you are a good target for a brute-force attack.` `The most obvious way to block brute-force attacks is to simply lock out accounts after a defined number of incorrect password attempts.` This has nothing to do with any password hashing algorithm. The pentest is right since you don't have one since you are not aware of it! – kelalaka Oct 28 '20 at 17:55

2 Answers2

4

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. 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).

Enos D'Andrea
  • 1,097
  • 6
  • 14
  • 1
    Where do you know that the server-client doesn't use TLS to hide the communication? Your second sentence is completely wrong. As long as the database is not hacked it is an online attempt to hack the passwords by trials. – kelalaka Oct 28 '20 at 17:52
  • 1
    @kelalaka I just meant that user credentials travel unchanged to the server, not that they can be sniffed. In any case I have applied the correction, thanks. – Enos D'Andrea Oct 29 '20 at 06:06
0

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.

mti2935
  • 21,098
  • 2
  • 47
  • 66