Pity they only went for 8 characters, though.
And by forcing more characters you may end up messing things up because people can start using patterns that defies the very core idea why there should be a 'minimum length'.
And rate limiting (see 5.2.2) should take care of most concerns about it.
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.
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.
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.
Actual OTP should allow you to print out or write down a set of codes.
That's way different from "I don't want to give out my phone number".
"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.
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.
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.
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.
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.
So the answer is: Some are already doing that.
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%.
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.
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.
[1] https://doc.satoshilabs.com/trezor-faq/threats.html#brute-fo...
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.
I wonder why this didn't establish in the first place...
Meanwhile, you can issue multiple simultaneous requests in parallel to try to authenticate the credentials, possibly from a large bank of distinct hosts.
Do human users authenticate faster than once a 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.
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.
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?)
Not in the case the hashes are leaked. However I agree very much with what you said otherwise.
> > 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.
Also, there is little evidence that entropy increases all that much when you force users to choose very long passwords.