Yes, and I like the approach that Trezor takes [1] for 4-digit PINs where the wait time increases by power of two. Also adding 2-factor authentication increases the security even on weaker passwords.

[1] https://doc.satoshilabs.com/trezor-faq/threats.html#brute-fo...

This is ripe for abuse. Case in point:

Back in my time in the military, there was an online portal that held your service information, the ability to request leave (time off), pay, etc. It was the place to go if you needed information aside from a paystub.

It required 8 char min, two upper, two lower, two special char (from a predefined list), and passwords would expire every 30 days. The thing is, most people knew all of their service info off of the top of their head. People also weren't requesting leave very often either, so most people would have to change their password on every login from some bullshit permutation of keyboard rolling with numbers and special chars tacked onto the end.

All that being said, you only had 3 attempts before lockout. No one wanted to risk lockout, so you'd make a throwaway password and reset it if you wanted to login. If you were locked out, it was a call to a civilian contractor with a hold time of 10-30 minutes just to get a temporary password emailed to you.

One of the easiest ways to fuck with someone was to intentionally lock out their account. It was trivial to find someone's username via searching through the email global address list. Then you pull up the portal, enter their user, smash the keyboard, and cackle as you have cost that person a guaranteed 10 minutes minimum just to do something trivial like print something from their file.

Trezor is an external device (like an smart card) that you have with you, not an external system that you can abuse.

I meant the wait time increase. If I don't like you (or am just a jerk in general), I'll just write a script to automatically retry 0000 after the lockout period. I'm not trying to break into your account; I'm just hassling you with a DoS attack.

I understand that and it is right but in the case of having a personal device with you, this attack will be stealing a physical object.

Unlimited doubling of wait time puts you right back to being vulnerable to DOS.

Surely DOS would only be an issue if the service literally sat there doing nothing for that period of time? Isn't the solution here just to reject all requests for that period of time doing the absolute minimum processing required?

Not DOS against the entire service, against a targeted user not being able to access the server (because you just entered a wrong password often enough that the system blocks his valid log-in attempts).

Yeah, after 3 failed attempts, just lock the user for 1 second. Brute force still will lead nowhere and real users will hardly notice.

I wonder why this didn't establish in the first place...

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 ^^

It's pretty meaningless to say "this is rate limiting not lock-out" when the rate limit is a ~7 hour wait between attempts. Many lock-outs automatically unlock faster than that! The comment you are replying to is correct, this is a DoS vector.

Heh, I often have more than 3 wrong password attempts. Lockout is a really bad idea for me.

I worked for a State government about 10 years ago. Some asshole managed to lock every single user's account by having a script attempt a login with an invalid password 10 times. Nobody could work for ~7 hours.

s/asshole/volunteer pentester/

Context is also relevant.

The iPhone for example has a PIN lockout, and young kids love phones.

More than once I've been punished by Apple for my kids curiosity.

You can disable this in Settings -> Touch ID and Passcode using the Erase Data toggle.

Not if your company overrides the settings. At my job, 5 is the limit, and then the phone is wiped. Seriously.

Can you explain those numbers? 7-12% of what? Are you suggesting that rate limiting reduces call volumes by a little more than half compared to lockouts? Where did you get the data?

In one large, diverse environment I'm familiar with, that policy spiked the need for intervention (password resets, unlocks, etc).

That spikes costs. Many users (mobile) need to call someone, which is $$$.

Those interventions also lead to things like figuring out what app stored password is relocking the account. That kind of exercise could cost a few hundred bucks.

...all for zero benefit.

I think s/he's saying that rate limiting leads to fewer password resets compared to lockouts. Which makes sense.