Multi-Factor Authentication: Overview, Definition and Case Studies

Introduction

Multi-Factor Authentication (MFA), also known as Two-Factor Authentication (2FA), requires users to provide more than one type of proof to authenticate to a system. There are four distinct types of proof (or factors):

Factor	Examples
Something you know	Passwords, PINs, and security questions
Something you have	Hardware or software tokens, certificates, emails, SMS, and phone calls
Something you are	Fingerprints, facial recognition, iris scans, and palm scans
Location	Source IP ranges and geolocation

It is important to note that requiring multiple examples of the same factor (e.g., both a password and a PIN) does not constitute MFA, although it does offer some security benefits over a single password.

The following sections also discuss the disadvantages and weaknesses of MFA. In many cases, however, these are only relevant in the context of targeted attacks. As a general rule: any MFA is better than no MFA.

Advantages

The most common way user accounts are compromised is through weak, reused, or stolen passwords. Despite all the technical security controls an application may implement, users tend to choose weak passwords or reuse the same credentials across multiple services. As a developer or system administrator, you should assume that user passwords will eventually be compromised -- and design your system accordingly.

Disadvantages

The primary disadvantage of MFA is the increased management complexity for both administrators and end users. Less technical users, in particular, may struggle with configuring and using MFA. Additional common challenges include:

• MFA methods that require specific hardware can introduce significant cost and administrative overhead.
• Users can be locked out if they lose or are unable to use their second factor.
• MFA adds complexity to the application. Many MFA solutions introduce external dependencies that can create security vulnerabilities or single points of failure.
• Processes implemented to bypass or reset MFA can be exploited by attackers.
• Requiring MFA may prevent some users from accessing the application entirely.

Recommendations

When and how to implement MFA depends on several factors: the application's threat model, the technical proficiency of its users, and the degree of administrative control available. These considerations must be evaluated on a per-application basis. That said, the following general recommendations apply:

• Give users the option to enable MFA with TOTP for their accounts.
• Require MFA for administrative or other highly privileged users.
• Consider exempting corporate IP ranges from MFA requirements.
• Allow users to mark their browser as trusted so they are not prompted for a second factor on every login.
• Implement a secure process that allows users to reset their MFA.

When Is Multi-Factor Authentication Required?

The most critical point to require MFA is at user login. Depending on the application's feature set, however, it may also be appropriate to require MFA for sensitive actions, such as:

• Changing passwords or security questions
• Changing the email address associated with the account
• Disabling multi-factor authentication
• Elevating a user session to an administrative session

If your application offers multiple authentication paths, all of them should require MFA or have equivalent protections in place. A frequently overlooked area is a separate login API or an associated mobile application.

Improving the User Experience

Frequent MFA prompts place an additional burden on users and may lead them to disable MFA altogether. Several mechanisms can help reduce this friction. Since these measures decrease the security that MFA provides, a risk assessment is necessary to strike the right balance between security and usability.

• Remember the browser: Store the user's browser as trusted -- either permanently or for a limited period. Use more than a simple cookie, which could be stolen by an attacker. For example, tie the cookie to the IP address range from which it was originally issued.
• Allow corporate IP ranges: Exempt known corporate networks from MFA (or, more strictly, use location as a second factor). Note that this does not protect against malicious insiders or compromised workstations.
• Require MFA only for sensitive actions: Instead of prompting for MFA at every login, reserve it for high-risk operations.

MFA Reset

One of the biggest challenges when implementing MFA is supporting users who lose access to their second factor. Common scenarios include:

• Reinstalling a workstation without backing up digital certificates
• Losing or resetting a phone without backing up OTP codes
• Changing a mobile phone number

To prevent users from being permanently locked out, a recovery mechanism must exist that allows them to regain access to their account. At the same time, it is critical that this mechanism does not enable an attacker to bypass MFA and take over the account.

There is no universally "best" approach to MFA recovery. The right solution depends heavily on the application's security requirements and the level of control over its users. Methods that work well in an enterprise environment where employees know each other personally may not be feasible for a public-facing application with thousands of users worldwide. Each recovery method has its own trade-offs, and these must be evaluated in the context of the specific application.