Limit attempt of user login against PBKDF2

Question

I have been tasked been tasked by my boss to change the encryption system of our web application from MD5 to PBKDF2 as MD5/SHA1 has been shown to be breakable in recent years .

I argued against it and thought we should allow users to attempt to login a maximum of 200 times a day , anything more would result in a locking of the user account . My rationale was that PBKDF2 would soon be broken in a few years time and we would have to change our encryption system again hence why not just limit the number of times a user can attempt to login. My boss however insists on me implementing PBKDF2

These are my following questions :

1) Is my rationale for wanting to limit the number of tries a user can login reasonable ??

2) Are there any flaws in my argument

3) Is my boss correct ???

Answer 1

1) Is my rationale for wanting to limit the number of tries a user can login reasonable ??

No, absolutely not the way you describe it. It's fine to limit the number of failed attempts in a short period of time and scale it up from there but you should never set a hard limit for a long period like an entire day. Who are you to tell me I cannot login to my account for the 201st time today?

2) Are there any flaws in my argument

Yes. MD5/SHA1/SHA256/SHA512 etc is stupidly flawed for password hashing. Also, PBKDF2 has been widely used for quite a number of years. There are no signs that it will be broken "in a few years". See this answer for more details.

3) Is my boss correct ???

Absolutely, yes.

Answer 2

I think the point that you're confusing here is the difference between online and offline brute force attacks. Essentially the two controls you're looking at are designed for different attacks and should both be applied (i.e. it's not one or the other)

Your idea of limiting user logins before lockout refers to an online brute force attack. this occurs where an attacker is attempting to guess the password via the application. Usually I'd recommend 10 incorrect logins before lockout, the reasoning being that if a user can't guess the password in 10 attempts they've forgotten it :) .

The hashing algorithm used to store passwords primarily defends against offline brute force attacks. These occur where the attacker has access to the hashed passwords and can try directly cracking them (e.g. not via the application). Here it would be correct to use PBKDF2 (or bcrypt or scrypt) as they are specifically designed for this purpose and will slow down the attackers guessing process.

The problem of using MD5 or SHA-1 is that these are not designed for password storage their are (partially) designed to be fast, which is a property we don't want when preventing an offline brute force attack.

Answer 3

1) Is my rationale for wanting to limit the number of tries a user can login reasonable?
2) Are there any flaws in my argument?

Quite, but not completely. First of all, 200 attempts is a huge number - most people will keep it under 20 per day, and I think of 50 as of a reasonable number of attempts.
However, the flaw in your "rationale" is locking people out of their accounts. As someone already noticed, an attacker knowing this vulnerability could use it lock people out of their accounts (this is more of a troll than an attack though). What I implemented on my website is:

1. Store the number of attempts in a file (the md5 hash of the attempted username) and update it if needed
2. Retrieve the current number of attempts. If it is bigger than, say, three, ask the user to answer a CAPTCHA first.

I think you should follow this kind of algorithm, i.e. Allow a reasonable number of "free" attempts, then challenge or otherwise slow down the user before logging him in.

---

3) Is my boss correct?

I don't see why stick to a particular algorithm, but yes, he is correct - PBKDF2 is currently a safe function (no attacks are foreseen). Plus, having a "number of desired iterations" is a very nice feature, since it increases the space where hashes (keys, really) are distributed [this feature is pretty much useless if any user can register to the service].
If it's really the case of a high-security environment, where security comes before performance, you might want to employ REALLY PARANOID STRONG stuff like ElGamal key generation, together with bcrypt.