The biggest takeaway is: MFA can prevent account takeovers where credentials are compromised. That's it.

Different forms of MFA exist, but in most cases enabling MFA is better than not enabling MFA - especially on important/crucial accounts.

From a security perspective, if the question is "Should I enable MFA?" Then yes, you definitely should. MFA is an added layer of protection from unauthorized account access.

What is MFA?

Multifactor Authentication (sometimes referred to as two-step authentication or 2FA) (MFA) is a multi-step approach to authenticating a user.

MFA requires a user to provide “proof” that they are indeed who they say they are, beyond providing the traditional username/password for logging in to a service/website.

For example, you may login to your bank from a public computer. While you know it’s you logging in, your bank may find it suspicious because you’ve never logged into your account from this machine before.

Different forms of MFA

There are different forms of MFA; some are more secure than others.

Text-message (SMS) and email based MFA are generally regarded as the weakest forms of MFA.

Time-based One Time Passwords (TOTP) and Fast Identity Online (FIDO2, generally hardware keys), are generally regarded as the strongest forms of MFA.

Weak(er) forms of MFA

SMS is an insecure protocol because it does not use encryption. With the rise of SIM-swapping attacks, where malicious actors successfully “steal” your phone number and port it over to a device totally under their control, SMS as a MFA method is far less secure.

Despite this, it is probably one of the most common forms of MFA used as of writing. Most US banks and other key financial institutions and government agencies primarily use SMS as a form of MFA.

Email is another common MFA method. While arguably more secure than SMS-based MFA (though this mostly depends on steps the user has taken to secure email accounts), email accounts are especially vulnerable to malicious takeovers from multiple attack vectors - especially phishing.

Email itself is still a popular vector for phishing attacks, so in theory a user’s email account could be compromised due to clicking on a malicious link sent directly to their inbox.

Strong(er) forms of MFA

TOTP (using an “authenticator app”) is considered a secure form of MFA for most users out there. The code users enter to satisfy the MFA requirements is randomly generated, using a shared secret between your authenticator and the server. The code expires after use, or if the “alive” period for the code lapses - whichever comes first.

FIDO2 is objectively the most secure authentication protocol available.

FIDO2 eliminates the need for shared secrets and allows for passwordless authentication in addition to supplying/supporting 2FA and MFA. In most cases, even if a user falls for a phishing attack, FIDO2 is phishing resistant. Some phishing attacks that may compromise the shared secret between the authenticator app and the server (thus, circumventing TOTP) are also thwarted if using FIDO2.

FIDO2 is typically used when authenticating with a hardware key, such as a YubiKey or NitroKey. Hardware keys replace verification codes in most cases.

TOTP is generally more common than FIDO2, but support for hardware keys is rapidly growing - for example, in January 2023, with the release of iOS 16.3, Apple officially introduced support for using a hardware key to lock/unlock the iPhone.

Why you should use (strong) forms of MFA

MFA protects against unauthorized access and account takeovers in the event login credentials are compromised.

In the modern threat landscape, there are many ways account credentials could become compromised, such as (but not limited to):

• A user could unknowingly install malware designed to harvest account credentials.
• A user could input account credentials into a convincing phishing website.
• A user’s credentials could be leaked in a data breach.
• A user could reuse a password (or one similar enough) that’s included in “combo lists.”

Given the amount of different attack vectors and threats to the confidentiality of login credentials, it’s also easy for users to underestimate due to no fault of their own; it’s difficult for this post to even capture all the nuances of how account credentials could be leaked.

However, let’s cover a few that most users are bound to experience…

Thwart some phishing attacks

While FIDO2 (typically hardware keys) is the only authentication/MFA method that is labeled as directly resistant to phishing, the presence of MFA can deter an otherwise successful phishing attack to attempted account takeover.

For example, let’s say a user is tricked into clicking on a malicious link. The malicious website presents itself as a carbon copy of the user’s banking website. The user enters their credentials into the phishing website, which then captures the credentials for the attacker to use later.

However, when the attacker attempts to sign into the user’s bank account, they must present the code sent to the mobile phone number on file for the account. The attacker does not have access to the user’s phone to retrieve the code, so the attacker fails the MFA step, effectively thwarting the unauthorized login attempt.

Naturally, in this specific example, if the attacker knew the phone number they could attempt to socially engineer the user to give up the code - but this is beyond the scope of this post.

To close the loop on this example, the user should be alerted that there was an unauthorized sign-in to their bank account. They should use a different device to visit the official and known domain for the bank, login, and change their password.

Combat weak or compromised passwords

Users frequently use (and reuse) fundamentally weak passwords. These poor practices help make password attacks like brute forcing and credential stuffing easier to successfully carry out for malicious actors.

Brute force and credential stuffing attacks

Brute force and credential stuffing attacks are nearly-always automated password attacking methods.

At their core, brute force attack assume user passwords are weak.

Brute force attacks are guess work, where the attacker(s) rely on raw computing power to try different combinations until coming across a “winner.” Technically, this password attack is considered “100%” successful because eventually there will be a correct guess - similar to trying every single combination on a padlock.

However, if the correct answer quite literally takes the attacker a million years to complete, even at thousands of guesses per second, then usually the juice isn’t worth the squeeze; a lengthy and complex password is simply harder to guess than a short, non-complex password.

In the scenario where your password is weak enough to be guessed (or a leaked hash cracked), then having MFA enabled on the would-be compromised account would stop the brute force attacker from gaining unauthorized access.

Credential stuffing assumes users reuse the same passwords across different accounts. Strength of the password is irrelevant if it is compromised. Malicious actors frequently take account credentials leaked in previous breaches, wordlists, and a variety of other methods to carry out credential stuffing attacks.

Like brute force attacks, credential stuffing campaigns are largely automated and target many thousands of accounts across different websites at the same time. Again, the bet is that users reuse passwords across many accounts; the attackers can also frequently avoid rate-limiting password failure attempts that commonly stop brute force attacks directly on many websites, web apps, and services.

In the scenario where a credential stuffing campaign is successful (typically due to password reuse) on an account with MFA enabled, then the MFA method would also stop the unauthorized access due to the attacker not having access to what you are, know, or have to complete the MFA step.

The ideal and most prominent solution to defending against brute force and credential stuffing attacks is using strong and unique passwords for all accounts; this is where the benefits of using a password manager absolutely shine.

Password managers generate and securely store strong and unique passwords. Not all password managers are created equal, so users should use a password manager that at least respects their privacy. If using a cloud-based password manager, then users should use password management solutions that are transparent in their infrastructure and security practices.

General advice for strong passwords is to make them a minimum of 20 characters long. Likewise, it is preferred to use methods that generate a “passphrase” (lengthy passwords, frequently in excess of 20+ characters) and incorporate some level of complexity and/or randomization.

Server-side Password Storage (Data Breaches)

A password, even if strong (or as strong as the service “allows”), could be compromised due to no fault of the user in the event the website, web app, or service suffers a data breach.

In many data breach cases, personal identifiable information (PII) is leaked, which can be combined with other leaks; some breaches even leak credentials, sometimes in plain text (!), but usually in a hashed format.

Over time, any leaked data can be compiled with other known/previously leaked data, or otherwise used by malicious actors to carry out a variety of attacks. Attacks vary widely, ranging from large scale phishing campaigns, money scamming attempts, or credential stuffing campaigns.

In the case of a leaked hashed password, attackers may choose to crack it. While a strong password’s hash will take more time to crack, if the hashing is weak or poorly implemented this may still be possible within a “reasonable” time frame in some circumstances.

Of course, it's important to remember time to crack may be rendered irrelevant if users reuse passwords across different accounts; the attackers could take this password and try it across other online accounts in credential stuffing campaigns.

Assuming secrets or a MFA service on the server wasn’t also compromised, MFA methods should thwart login attempts that do not present the required factor, even if the correct account credentials (username and password) are provided.

In most service-side or company-related data breaches, it’s generally recommended for users to change their passwords for affected accounts.

Data breaches don't only just affect users the service that was breached; they can have ripple effects across any user's digital life, especially if they reuse passwords and don't enable MFA on crucial accounts. You should enable MFA on at least crucial accounts due to the proliferation of data breaches; you may have a strong and unique password, but your credentials could be compromised due to a leak or any breach.

Notification of attempted account takeovers

MFA can alert users of malicious activity occurring on their accounts in close-to real time. This is secondary to preventing unauthorized account access from leaked credentials.

In most cases, MFA methods generally trigger immediately, so users can provide the requested MFA factor and then sign in promptly.

If you know you did not attempt to login to that service, and you received an SMS/email/push notification with a code for completing a login in - you are now informed that something is amiss. Whether this was a glitch or an unauthorized access attempt, you can now investigate and take action quickly, if needed.

Usually, actions users will need to take include:

Many websites, web apps, and web-based services will notify users of a failed authentication attempt. For example, Google will send a “critical security alert” in the event the correct email/password is provided, but the MFA factor was not successful. This is generally separate from an account lockout due to too many failed login attempts.

A note on backup methods

Strong(er) MFA methods are not risk free (nothing in cybersecurity is) - you can become locked out of your accounts if you lose your MFA factor. For example, if you had an authenticator app installed on your phone for TOTP and you lost your phone, you would be effectively locked out of your accounts.

However, when you enable TOTP, services generate backup codes; these codes should be used if you do not have access to your MFA method. Properly managing (read: storing) backup codes is highly important, as they become lifeline for regaining access to your accounts. Most services where TOTP is available do not have an easy reset process for MFA lockouts, if they have one at all.

For hardware keys, hardware key vendors typically say you should buy two - and keep one as a spare in the off chance you lose your primary hardware key.

Final thoughts

MFA primarily prevents account takeovers where user credentials are compromised, but it can also serve as an “early warning detection system” for the end user.

While there are varying security “levels” to MFA factors, at the end of the day, all MFA provides an added layer of protection for user accounts. The strongest and most ideal forms of MFA are TOTP and hardware keys; some services/websites do not offer these, but if they do, users should use TOTP and hardware keys where available.

There are many ways account credentials can be compromised, putting user accounts at risk, whether via data breaches or a successful credential stuffing campaign.

Enable strong(er) forms of MFA where possible; ideally users would use hardware keys supporting FIDO2. However, despite some weaknesses, TOTP is also a good and relatively strong option for MFA.

Remember: for security purposes, in most cases, you are better off enabling MFA for accounts than not!

With that said, stay safe out there!

Acknowledgements

Thanks to user defr0ke for bringing up backup codes in case of lockout.