Rate limiting is better than lockout.

Other federal agencies (IRS in particular) require lockouts with only 3 bad password attempts. That generates really high reset/unlock call volume -- easily 20-30% of users require intervention or reset compared to 7-12%.

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.

> This is prone to a DoS attack.

When will we see the first organization (government or private) that is effectively completely DoS'ed for days on end because their login does this, while all their email addresses are listed on their website? If sustained, I imagine this could shut down an entire organization quite effectively for a few days. Probably could lose someone millions. Or add insult to injury, and have them pay BTC for the attack to stop.

Sometimes I definitely scare my coworkers just by caring about such edge cases. They probably think I use foil hat at home :)

Such an organization might investigate the use of stored tokens so that all users don't have to be authenticated simultaneously.

> Though, I think this is bad

> > Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single account in any 30 day period.

> Well, imho there MUST be no limit. This is prone to a DoS attack. Rate limiting and other things MUST be able to solve this one way or another.

I agree. Nobody is going to guess a good password in 100 attemps, or 100,000,000 attempts. A tiny bit of rate-limiting, like one login attempt/second, should be enough to prevent successful brute force on good passwords.

The threat is hacking the database of hashes and brute-forcing offline.

>rate limiting (see 5.2.2) should take care of most concerns about it.

Not in the case the hashes are leaked. However I agree very much with what you said otherwise.

When I am limited to only 8 characters it's always a bank account.

I've found the best way to get around this limit is to give the account information to my payroll department and then never access it.

> I've found the best way to get around this limit is to give the account information to my payroll department and then never access it.

Maybe I don't understand, but isn't the issue not your access to it, but others'? If you are forced to have a weak password protecting sensitive information, then it's an issue even if you never need to access that information yourself. (Or maybe you mean that you never even establish the account, and hence the weak password, in the first place?)

Merely wordplay on leaving your money in an account and letting it accumulate. Was continuing on the "8 character limit in my bank account" double meaning.

Then consider this a rate limit with average of 3.3 attempts per day over a 30 day period.

Except this is a rate limiting on the account globally, and here lies the DoS problem. So if you follow it you can theoretically have your account locked down by an idiot on the other side of the world.

You can minimize this by making it per IP, for example. So, you'd have to have an idiot on your home. Yeah, maybe this is not 100% bullet proof given IPv6 and so on, but at least this doesn't introduce a vector for DoS.

Rate limiting per IP is close to useless, since it is trivial for an attacker to attempt connecting from different IPs.

How trivial is it? Would an attacker wanting to do one million attempts easily be able to send each from a different ip?

Most of the time when I see large scale password cracking attempts against customer servers, I have to block large blocks because they're coming from large number of IPs. I had to block most of South Korea at one point, because we saw abusive traffic from millions of IPs belonging to a couple of major ISPs in South Korea (thankfully non of our customers had much if any legitimate traffic from outside Europe at the time).

So the answer is: Some are already doing that.

Bad guys can easily rent time on botnets with hundreds of thousands of ips.

So the solution for you seems to be allowing bad guys DoS your system because bad guys can do bad things, is it?

Is per-IP rate limiting the only one way to respond to auth DoS? Different situations involve different trade-offs.

Rate limiting. Not denying service. Bad guys could cause you to have to wait some number of seconds to log in.

> Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single

I think that can be read two ways.

1) 100 failed attempts/account/month 2) 100 failed attempts/IP/account/month

The latter still limits an attacker but is less likely to be a plausible DoS against the account unless the attacker has compromised the legitimate user's machine at which point all is lost anyway. Later in the same section:

> When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts from the same IP address.

Which suggests the failure count is per IP and not per account.

that part is saying that once an IP gets a password correct, don't count past mistakes against them.

You mitigate that by putting MFA in front.

MFA is basically another key|password. If I am not careful with my secret key and password what difference does it make that there are two of them?

No, security is tough. The better security the less useful it is. NIST got this right. Do what you can, don't kill the user and implement security on the aaa side.

Have you ever messed with a friend by locking out their phone?

I was specifically addressing the DoS vulnerability of locking an organization out en masse by taking advantage of account lockout or timeout policy. A list of emails and a six line script could take a whole company offline.

MFA can be used to address that by requiring pre-auth before you can enter a password.

MFA is not a magic solution to all problems either. You can't expect me to give my phone number or real email address to every random site I login into.

You don't need to do that for HOTP/TOTP though.

1. Scan a QR code.

2. You now have a secret value that can generate a deterministic pseudorandom integer securely indefinitely.

Also, SMS-based MFA should be burned to the ground.

Scanning a QR code by hand is easy when you don't have the phone handy. (sarcasm)

Actual OTP should allow you to print out or write down a set of codes.

> Scanning a QR code by hand is easy when you don't have the phone handy. (sarcasm)

That's way different from "I don't want to give out my phone number".

Both are impossible when not having a phone.

It's non sequitur.

"I have a phone number but don't want to give it out" is different than "I don't have a phone".

But hey, there are 2FA devices you can use instead.

This is why I'm a big fan of the U2F standard, which allows a device (generally a small USB/NFC device) to generate shared secrets for arbitrary services without exposing any personal information.

Think about this problem in context with the NIST trust level framework.

Nobody gives a shit about low trust environments... go ahead and crack my slashdot account, but higher trust stuff like mail, money, network access etc absolutely need MFA.

That's my point. MFA itself is certainly a very useful security solution (for example, I wouldn't trust a bank that doesn't use it), but "MFA everywhere" is not a way to go, because I value my privacy more than some useless Internet account.

A security key should work.

Rate limiting seems like a good application of neural networks. Find out when hackers tried a lot of passwords and when users tried a lot of passwords. Run that data through a model and you can get a model that changes as hackers change their attack methods. Although you'll have to manually classify hacking attempts vs. real users.

8 is nowhere near good enough.