Why wait until 3 tries? Why not just require 1 second between all attempts?

Hmm, I guess this makes sense. Not sure what I was thinking...

if you're hashing with PBKDF2 and 100k+ iterations, it can take that long anyway.

But not in parallel.

Can hashing iterations be conducted in parallel? Doesn't the next hash need the output of the last, making this a sequential operation?

Both of you are correct, just talking about different things. PBKDF2 rounds are clearly sequential.

Meanwhile, you can issue multiple simultaneous requests in parallel to try to authenticate the credentials, possibly from a large bank of distinct hosts.

> Yeah, after 3 failed attempts, just lock the user for 1 second.

Do human users authenticate faster than once a second?

Assuming a web page, does the page reload in less than 1 second?

On a full sized keyboard, the normal rate is 3.3 key presses per second. On a mobile device, I'm sure an 8 character password will take far more than 1 second.

For brute force attack defense, rate limiting a single account globally to 1/sec, i.e. independent of source IP address, should be sufficient and prevent parallel attacks by bots, but this still makes DOS attacks on a particular account easy, but not the entire system except traditional overload.

Many API systems work this way and it's proven effective.

So, why not always lock the page for 1 second post failure, rather than try to capture a 3rd strike policy?

The login page probably can't be loaded in 1 second ^^