How to protect MFA against brute force attacks

Multi-factor authentication (MFA) undeniably boosts security – this much we know for sure. Yet it remains a complex technology that often ends up being a trade-off between security and convenience. Attackers know this, betting that defenders will either fail to apply MFA widely enough or will make mistakes when implementing it.

We’re seeing more and more types of MFA bypass attacks – like phishing and MFA fatigue – as attackers learn how to better exploit vulnerabilities.

One method we’ve seen recently in high-profile MFA breaches is brute force attacks. Let’s dig into what a brute force attack is, and how to protect against it.

The real culprit: MFA complacency

MFA’s greatest weakness lies not in the strength of the technology itself, but in its implementation. More often than not, MFA is not implemented across the board (read: across all users). Some teams require MFA at every login, but others don’t. For some teams, MFA might even be turned off. All too often, the assumption is that by locking the most important points of entry behind MFA, an organization has reduced its attack surface.

Unfortunately, and we do apologize for the shattered glass, this is an illusion.

Because attackers can systematically probe for a weak account, an organization is only as strong as its weakest credential.

How do MFA brute force attacks work?

A second problem has to do with the design of MFA itself. It’s common knowledge that some types of MFA methods are not secure. A prime example: one-time codes sent via SMS are not secure. However, even relatively secure types of MFA can also be vulnerable.

Attacks like brute force target these relatively secure methods of MFA where there are weaknesses because of how MFA is implemented.

What is a brute force attack?

Brute forcing is really a sophisticated form of guessing. It uses computing power to cycle through large numbers of possibilities until the correct one is found. To shorten the odds, attackers usually employ a dictionary attack in which common combinations of letters, words, or numbers (“IheartNYC123”) are tried first. They are also aided in this by a technique called time-based enumeration which exploits the fact that valid logins are revealed by the fact they take longer to process than invalid ones.

How do brute force attacks threaten MFA?

When MFA is carefully implemented, brute force shouldn’t be a threat. MFA that requires time-based, one-time passwords (TOTP) rather than static data (like a login credential) in theory changes with each login attempt. Unfortunately, some MFA implementations are more lax around these parameters.

When the odds are not in your favor…

If we assume an attacker already has working password credentials (or has brute-forced the correct password using one of the above techniques) their next problem is to find a way past the MFA prompt. This sounds insurmountable, but consider that MFA prompts are typically short sequences of numbers. If that is a four-digit number (digits 1 to 9 + 0) – a far from uncommon default – the attacker only has to guess from 10,000 possibilities.

This rises by a factor of ten for every extra digit, which means that the default six-digit code has one million possibilities. This is only a large number of guesses if the MFA platform rate-limits the number of failed login attempts, which it almost invariably will. This stops attackers from just endlessly guessing the correct MFA code. However, if the account itself doesn’t automatically lock after a set number of incorrect attempts, the attacker can simply launch a new MFA guessing session and keep trying.

This leads to one of two outcomes:

• In the best-case scenario for the attacker, the MFA code is not reset, which means the attacker can keep trying, excluding codes that haven’t worked previously.

• But even when the code has been reset, the game is not over because they are still given two or more guesses for each MFA guessing session. Assuming a four-digit MFA code, that means they still have at least a two in 10,000 chance of guessing the correct code; even higher if they narrow their focus to common code patterns (for example, year dates beginning 19xx or 20xx).

The main defense against this is to lock accounts where too many failed logins have been attempted. However, organizations are sometimes reluctant to do this because it can lead to a denial-of-service situation where lots of accounts are locked, bringing an organization to its knees while overloading the admins with work investigating and reinstating access.