Multi-Factor Authentication: Overview, Definition and Case Studies

Introduction

Multi-Factor Authentication (MFA) or Two-Factor Authentication (2FA) is when a user is required to provide more than one type of proof to authenticate to a system. There are four different types of proofs (or factors) that can be used, listed in the table below:

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 should be emphasized that requiring multiple examples of one factor (e.g., requiring both a password and a PIN) does not constitute MFA, although it does provide some security benefits compared to a simple password.
In addition, the following sections discuss the disadvantages and weaknesses of MFA, although in many cases they are only relevant against targeted attacks. To begin with, any MFA is better than no MFA.

Advantages

The most common way that user accounts in applications are compromised is through weak, reused, or stolen passwords. Despite all the technical security controls implemented in the application, users are likely to choose weak passwords or use the same passwords on different applications. As developers or system administrators, it should be assumed that user passwords will be compromised at some point, and the system should be designed to defend against this.

Disadvantage

The main disadvantage of MFA is the increase in management complexity for both administrators and end users. Many less technical users may have difficulty configuring and using MFA. In addition, there are a number of other common problems:

Types of MFA that require users to use specific hardware can add significant cost and administrative overhead.
Users can be locked out if they lose or cannot use their other factors.
MFA adds complexity to the application. Many MFA solutions add external dependencies to systems that can cause security vulnerabilities or single points of failure.
Processes implemented to bypass or reset MFA can be exploited by attackers.
Requiring MFA may deny some users access to the application.

Recommendations

Exactly when and how MFA is implemented in an application depends on a number of different factors, including the threat model of the application, the technical level of the users, and the administrative level of control over the users. These must be considered individually for each application. However, generally applicable recommendations are as follows:

Give users the option to enable MFA for their accounts with TOTP.
Require MFA for administrative or other highly privileged users.
Consider allowing enterprise IP ranges to not require MFA from them.
Allow users to remember to use MFA in their browser so they are not prompted to do so every time they log in.
Implement a secure process to allow users to reset their MFA.

When is Multi-Factor Authentication Required?

The most important place multi-factor authentication is required in an application is when the user logs in. However, depending on the features available, it may also be appropriate to require multi-factor authentication for performing 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 the application provides multiple ways for a user to authenticate, all should require MFA (multifactor authentication) or have other protections implemented. An often overlooked area is if the application provides a separate API for logging in or has an associated mobile application.

Improving the User Experience

Frequent logins with MFA creates an additional burden for users and may lead them to disable MFA in the application. A number of mechanisms can be used to reduce the hassle that MFA causes. However, these measures reduce the security provided by MFA, so a risk assessment must be performed to find an appropriate balance between security and usability for the application.
Remember the user's browser so that they do not have to use MFA every time. This can be either permanent or for a period of a few days. This needs to be done with more than just a cookie that could be stolen by an attacker. For example, a cookie that corresponds to the previous IP address range for which the cookie was issued. Allow corporate IP ranges (or, more strictly, use location as a second factor). This does not protect against malicious insiders or compromise of the user's workstation. Only request MFA for sensitive actions, not initial login.

MFA Reset

One of the biggest challenges in implementing MFA is helping users who forget or lose their second factors. There are many ways this can happen, such as: Reinstalling a workstation without securing digital certificates. Deleting or losing a phone without securing OTP codes. Changing the mobile number.

To prevent users from being locked out of the application, there must be a mechanism for them to gain access to their account if they cannot use their existing MFA; however, it is also critical that this does not allow an attacker to bypass the MFA and take over their account.

There is no clear "best way" to do this, and what is appropriate will greatly impact the security of the application and also the level of control users have. Solutions that work for an enterprise application where all employees know each other are probably not feasible for a publicly available application with thousands of users around the world. Each recovery method has its own advantages and disadvantages, and these must be evaluated in the context of the application.