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.