Is login limiting still needed if we employ multi-factor authentication?

Question

The status quo is that most online websites limit login attempts per IP address, or even per account since some attackers possess huge amounts of IP addresses.

Removing login limits would have the advantage that attackers would no longer be able to fraudulently deny access (availability) to legitimate users, be it by IP address or by account. OWASP declares:

When multi-factor is implemented and active, account lockout may no longer be necessary.

How true is this statement? Does it mean that if our website employs mandatory multi-factor authentication (e.g. Google Authenticator), we can then safely remove our "IP address login limit" and "per account login limit" mechanism?

Is it still possible to brute force through multi-factor authentication if there are no login limits?

Answer 1

If login rate-limiting is implemented properly, then there are no downsides, and it should be used with or without 2FA (and in fact with the 2FA attempts themselves). And account lockout is not the proper way to rate-limit login attempts.

Rate-limiting means you restrict the number of attempts a given source can make. Typically this means a given IP address, though you can define "source" however makes sense in your situation.

There are really three types of attacks you're trying to defend against here:
(a) The attacker knows the password -- in which case lockouts won't help even a little.
(b) The password is easily guessed, like "123456" or "passw0rd", or "zxcvbn". Again, account lockouts won't be helpful because these attackers don't try more than 5 or 10 passwords at the most before moving to the next account. Often they'll try only one. You need to block the attacker, not the account. (c) The attacker is making a determined go at a single high-value account and will try the whole dictionary and then some. The password may not be easy to guess, but the attacker has all month.

There's not much we can do about condition (a) above, though 2FA can help. Condition (b) is extremely common while (c) is a bit more rare because the success rate is so low. But importantly, both can be thwarted by slowing down the attacker.

Ideally this doesn't mean a hard limit of 15, and then you wait 10 minutes. Ideally you do an exponential back-off. This means after 2 attempts, you wait several seconds. After the third, you wait a bit longer. And then longer after the fourth, and so forth. The limit is enforced in the back-end, and in the front-end you use some client-side logic like a timer in javascript to keep the user from submitting attempts during the waiting period.

I've explained this technique here several times, so I won't go too deep into the details. But the important thing is that it is simple to build, doesn't noticeably inconvenience legitimate users, but it does work very well against determined attackers. By slowing them down, you're effectively setting a hard limit on how many attempts they can make in any given timespan, but doling out that limit incrementally between attempts. And better still, you can detect which users continue to send attempts during the waiting period, which flags them as using specialized software to circumvent your client-side rate-limiting. Cool!

If you set things up like this, then there's no reason to disable rate-limiting. It has no real drawbacks, is largely invisible to users, and offers a reasonable front-line of defense against brute-force attackers.

This only leaves the scenario of a distributed attack against a single login from a large botnet. This is rare enough to never actually happen for most sites, but it's simple enough to detect and address, so I'll leave that as an exercise to the reader.

Answer 2

If 100% of your user base uses 2FA on all logins then it may not be as important, however you may still need to rate limit your 2FA attempts at the very least. Some services only use a 4 digit code sent via SMS with a 5 minute window, in which case it's plausible an attacker could brute force the code. In other words, you probably still need rate limiting somewhere to avoid becoming less secure.

I'd still recommend rate limiting both logins and 2FA though:

• Cryptographic functions are typically computationally expensive, so an attacker could potentially mount a DOS attack by performing a high volume of invalid login requests.
• You don't know whether your users device has been compromised or stolen, attackers may still attempt a brute force attack then.
• 2FA is usually opt-in so it's rare to have 100% enrolment, and otherwise you'd still need to rate limit users without 2FA.

Answer 3

I recommend rate-limiting as well. Better to keep an eye on things.

Here's what we do in the WiKID server. The server will lock the user out after a (admin configurable) number of bad passcode attempts, but it will ignore non-numeric passcodes. This keeps a user from being locked out by a simple brute force attempt but protects you from someone guessing codes.

We create a log entry that a non-numeric passcode was attempted. We recommend reviewing these to see if the attacker is using a valid, stolen credential.

(Note that some time or counter-based tokens can be configured so that more than one passcode can be valid at a given time to allow for re-syncing for clock/counter drift.)