By Dean H. Saxe (Amazon) and Khaled Zaky (Amazon)

© 2022 IDPro, Dean H. Saxe, Khaled Zaky

Introduction
This article describes multi-factor authentication (MFA), a key component in securing account access and guarding against account takeover. Organizations and individuals typically have multiple types of MFA and several strategies for implementing its use. Not all MFA offers the same level of security, and some types of MFA are generally not recommended.

Terminology

Many of these terms have been sourced from “Terminology in the IDPro Body of Knowledge.” ¹

What is Multi-factor Authentication?

MFA is an authentication mechanism that requires a user logging into an application or an online account to present two or more factors to sign in and complete their authentication flow. Traditionally this would have been just a username and a password combination or another form of single-factor authentication, such as fingerprint biometrics. Adding multiple factors reduces the likelihood of bad actors gaining unauthorized access in case any of the factors are compromised. For example, single factors, such as passwords (which are subject to reuse and compromise), are one of the most common ways malicious actors can gain unauthorized access to your accounts, data, and online assets. Adding additional factors reduces the risk of account compromise and raises authentication assurance. Check out the NIST 800-63-B, which provides recommendations on types of authentication processes, authenticator types, and various assurance levels. ²

There are three types of MFA factors:

• The knowledge factor is something you know . This factor could be something like a password or a PIN code.

• The possession factor is something you have . This factor could be something like a USB key, a smartphone, or an access card.

• The inherence factor is something you are . This factor could be a biometric, like facial recognition, fingerprint, or voice recognition.

What is the Difference between MFA and 2FA?
Two-factor authentication, or 2FA, is an identity and access management authentication method that requires exactly two factors of identification to gain access.  It is worth mentioning that 2FA is sometimes referred to as two-step verification or 2SV in some online services. 2FA is usually used interchangeably with MFA. However, in the case of MFA, more than two factors can be required,  such as a combination of password + one-time password (OTP) + on a device with mobile device management (MDM). Therefore, 2FA is a subset of MFA.

History of Multi-factor Authentication

How did the industry come to embrace MFA?  Although the original ideas and patents are up for debate, we can say that the concept of MFA was first commonly used with automated teller machines (ATMs, cash machines).  First introduced in Europe in 1967 , ATMs required a physical card containing information encoded on the magnetic stripe as the possession factor (something I have) and a PIN (something I know) to conduct bank transactions. ³

The breakthrough in security was the idea that a public number (PAN) was to be combined with a private identification number (PIN). The PAN was printed in punched holes on the card and of course, could be forged. It would be secured through the use of a PIN that would correspond to the PAN through a complex coding system. The key was that such system should be of sufficient strength to prevent anyone getting to the PIN from the PAN. Chubb tested the system by printing off 1001 cards and attempting to break this system. They failed and Goodfellow’s system became the basis of the security system in the ‘Chubb MD2’ cash dispenser. Goodfellow’s patent was filed on May 2, 1966 (GB1197183). ⁴

In 1987, RSA introduced the first hardware key fob, enabling the use of one-time passwords (OTPs) as an authentication factor.  These hardware key fobs are still in use today and sold by numerous vendors using both Time-based One Time Passwords (TOTP, see RFC6238 ) ⁵ and HMAC-Based One Time Passwords (HOTP, see RFC4226 ). ⁶

By the early 2000s, MFA solutions began to see a broad rollout in enterprise, government, and consumer use cases.  In 2004 the United States Homeland Security Program Directive 12 (HSPD-12) was signed by President George W. Bush.

“US policy is to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy by establishing a mandatory, Government-wide standard for secure and reliable forms of identification issued by the Federal Government to its employees and contractors (including contractor employees). This directive mandates a federal standard for secure and reliable forms of identification.” ⁷

In response to HSPD-12, the US Federal Government, through the National Institute of Standards and Technology (NIST), released FIPS-201-1 , specifying the requirements for Personal Identity Verification (PIV) for US Federal Government employees and contractors. ⁸ NIST Special Publication 800-73-1 ^[xi] , released in March 2006, “specifies the PIV data model, Application Programming Interface (API), and card interface requirements necessary [...] for interoperability across deployments or agencies. Interoperability is defined as the use of PIV identity credentials such that client-application programs, compliant card applications, and compliant integrated circuit cards (ICC) can be used interchangeably by all information processing systems across Federal agencies.” ⁹

In December 2004, the US Federal Deposit Insurance Corporation (FDIC) released the paper “ Putting an End to Account-Hijacking Identity Theft, ” which concluded with the recommendation for “upgrading existing password-based single-factor customer authentication systems to two-factor authentication.” ¹⁰ Shortly after that, in 2005, the Federal Financial Institutions Examination Council released guidance for the US banking industry entitled “ Authentication in an Internet Banking Environment, ” which stated, “The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties. Financial institutions offering Internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services.” ¹¹ The requirements were not compulsory.  In 2011, the RAND Corporation noted:

The financial sector is potentially the most varied in its implementation practices. Despite regulations (more like “guidelines”) that require financial institutions to protect certain data to a certain minimum level and indicate that MFA meets these criteria, organizations in this sector make network access decisions internally. ¹²

These changes did not arrive without debates about their value and consumer concerns about using MFA. ¹³ First deployed in Nigeria in 2005 by Neticash, SMS OTP was broadly adopted in the 2010s.  At the same time, consumer use of OTPs became more common with readily available authenticator apps, such as Google Authenticator, becoming available for various smartphone devices.

The FIDO Alliance was founded in 2012 to develop a password-less authentication protocol and later, an open, second-factor protocol. ¹⁴ The World Wide Web Consortium (W3C) released the first WebAuthn specification in conjunction with FIDO Alliance Client to Authenticator Protocol (CTAP) in March 2019, enabling FIDO2 as a phishing-resistant authentication protocol across platforms, browsers, and devices. ¹⁵ With the public release of passkeys by the FIDO Alliance, W3C, and commercial partners in 2022, the tools for strong, highly phishing-resistant authentication already exist in many consumer and enterprise devices such as laptops, tablets, and phones. ¹⁶

Bruce Schneier wrote in 2005, “Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions. It solves the security problems we had ten years ago, not the security problems we have today.” ¹⁷ Schneier’s blog post was prescient.  Even after the broad rollout of MFA mechanisms starting in 2005, we are still fighting against phishing, fraud, and identity theft in the 2020s.  As the industry has adapted to these ills, malicious actors have also adapted their mechanisms.  As we close the front door with better technology, what new paths will actors take to achieve their nefarious goals?

Why Choose Multi-factor Authentication?

The key benefit of adopting MFA is that it improves individuals' and enterprises' security posture and delivers a higher level of assurance to guard against unauthorized account access. With MFA enforced, users are required to authenticate by presenting multiple factors, for example, a username, password, and fingerprint from their device. These additional factors reduce the risk of unauthorized access when one of the authentication factors is compromised, such as a leaked password through a third-party data breach or a phishing attack. You can think of every factor added as an additional lock as an access security layer to prevent unauthorized users from breaking in.

The Problem with Single-Factor Authentication

Single-factor authentication is when access is provided when a user presents one factor. This presentation could be in the form of a password, access card, or fingerprint biometric. The most common single-factor authentication mechanism is the password. Password-less mechanisms, such as passkeys, designed to replace passwords as an authentication factor, are expected to see broad consumer rollout after their introduction in 2022.

However, passwords are still the most widely used mechanism to authenticate to various online services. Passwords are vulnerable to various attack techniques commonly used by attackers to gain access to online accounts. Here are some examples of those techniques:

• Identity Theft: This is when an attacker illegally acquires personal information such as date of birth, credit card details, or even answers to security questions that could be used for password guessing or resets.

• Phishing: This is when an attacker falsely presents themselves as a trusted party through fraudulent emails, websites, or pop-ups, hoping that they collect someone’s personal information, such as username/password.

• Brute force: This involves an attacker guessing username and password combinations in hopes that they would eventually gain unauthorized access to an account

• Credential Stuffing: This is when an attacker uses a list of known compromised passwords to take over someone’s account.

• Key-logging: This requires an attacker to compromise the end-point like a public computer where they would have installed a key-logger to monitor and record actual keystrokes for personal information such as login information and credit cards.

• Man in the middle: An attacker could use URLs that closely resemble the intended website. This deceptive URL is then used to direct the user to a reverse proxy server used by the attacker to intercept the communication between the user and the intended website in order to steal sensitive data, such as a user’s password.

The introduction of passkeys presents an interesting dilemma: Are passkeys an MFA mechanism when they are syncable across cloud services? What about when they are resident on a single device? If passkeys are primarily designed as a single authentication factor to replace passwords, will we see passkeys deployed with additional factors? With varying security models depending on where the passkeys are generated and how they are stored, synced, and shared, we believe it is likely that some passkey implementations will require additional authentication factors. For additional passkey considerations, see the FIDO section below.

Multi-factor Authentication Mechanisms

Grid Cards & Grid-Based Mechanism

Possession Factor: Card

Knowledge Factor: Password

Inherence Factor: None

Phishing Resistance: None

A form of a challenge-response protocol, a unique grid with named columns and rows is printed on card stock, a plastic card (e.g., student ID), etc. ¹⁸ At each set of coordinates is a cell containing an alphanumeric value.  Upon first factor authentication with a password, the user is presented with a dynamic challenge requiring entry of the values at multiple coordinates on the grid as a second factor.

Credential Calculators Hardware Token

Possession Factor: Credential Calculator

Knowledge Factor: Password

Inherence Factor: None

Phishing Resistance: None

In another form of challenge-response protocol, users authenticate to a service with a password and receive a numeric challenge.  This challenge is entered into the device using a keyboard, and the response is calculated.  The user enters the output into the service to complete the authentication process.

One-Time Passwords - HOTP

Possession Factor: HOTP Generator

Knowledge Factor: PIN or Password

Inherence Factor: None

Phishing Resistance: None

Described by RFC 4226 as “An HMAC-based One Time Password Algorithm,” HOTP is a commonly used second factor.  Successive HOTP values are generated through the application of the HMAC-SHA1 algorithm, whose inputs are a static seed value, unique per device and shared with the server, and the counter, a numeric value that increments on each iteration.  The output is truncated to a set of human-readable numbers, often 4-8 bytes in length.

Generally found on hardware devices with small display screens showing a set of numbers after pressing a button, the HOTP output is entered into a form field by the user to complete authentication.  Of note with HOTP generation is that the codes are generated dynamically in response to a user action, such as a button press.  This can lead to devices becoming out of sync with the server state when multiple HOTPs are generated by the client and unused.  Desynchronization must be addressed through a re-synchronization process that is undefined by RFC.

One-Time Passwords - TOTP

Possession Factor: TOTP Generator

Knowledge Factor: PIN or Password

Inherence Factor: None

Similar to a HOTP, a TOTP is defined by RFC 6238 as a time-based one-time password algorithm.  The RFC describes TOTPs as a “variant of the HOTP algorithm [that] specifies the calculation of a one-time password value, based on a representation of the counter as a time factor.”  Since the successive values are not generated in response to a user action, desynchronization is less of an issue with TOTPs vs. HOTPs, assuming the services are not subject to excessive clock-skew.

Similar to HOTP, TOTP is often implemented in hardware devices with a small display screen that is constantly refreshed over time, displaying 4 to 8 digits.  Additionally, TOTPs are often implemented by software such as password managers, Authy, etc., as a convenient mechanism for users with smartphones to carry multiple TOTP generators for different services on a device they already possess.  In this case, the user will scan a QR code with their TOTP software application, instantiating the TOTP in the software.  The user then enters the current TOTP into the relying party’s service to validate the TOTP has been instantiated correctly.  These TOTPs may exist on multiple devices, either through a cloud-based sync or re-scanning the QR code on multiple devices as a backup of the TOTP generator.

TOTP, like HOTP, was developed by the Initiative for Open Authentication, an industry group that developed the open specifications, which later became IETF RFCs. The standards developed by OATH enabled the creation of an ecosystem of hardware devices and software implementations, eliminating the need for context-specific second factors.

One-Time Passwords - SMS (Short Messaging Service)

Possession Factor: Access to SMS on a mobile device

Knowledge Factor: PIN or Password

Inherence Factor: None

SMS OTP allows a user to authenticate using a one-time password sent over to the user’s mobile number using SMS.  The user configures their phone number with a relying party to receive OTPs during authentication. As noted above, NIST-800-63rev3 identifies SMS OTP as a “ restricted ” authenticator.

“The use of a RESTRICTED authenticator requires that the implementing organization assess, understand, and accept the risks associated with that RESTRICTED authenticator and acknowledge that risk will likely increase over time. It is the responsibility of the organization to determine the level of acceptable risk for their system(s) and associated data and to define any methods for mitigating excessive risks. If at any time the organization determines that the risk to any party is unacceptable, then that authenticator SHALL NOT be used. ¹⁹

Verifiers SHOULD consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret.” ²⁰

One-Time Passwords - Email

Possession Factor: Email address (no physical possession)

Knowledge Factor: PIN or Password

Inherence Factor: None

Email OTP allows a user to user to authenticate using a one-time password sent over to a registered email address registered to the user’s account. The user must provide the OTP value during the authentication ceremony.  The security of email OTP is dependent upon the security of the user’s email service.

One-Time Passwords – Magic Links

Possession Factor: Indeterminate

Knowledge Factor: Indeterminate

Inherence Factor: Indeterminate

Magic links provide a fast and easy sign-in user experience. Users are authenticated by providing their email address only; they are then sent an email with a link for the user to click and complete their sign-in. This link is an embedded token that can only be used once. This provides a password-less login experience, which has many user experience advantages. However, it is worth mentioning that magic links are only as secure as a user’s email address. For example, if someone gets access to a user’s inbox, they can now access the magic links as they get sent to the user, which might lead to an authorized access event. Therefore, we classify the possession, knowledge, and inherence factors are indeterminate – the security is dependent upon the authentication credentials to the email service and any devices which have persistent access to the same.

FIDO U2F / FIDO2

Possession Factor: Devices such as a phone, tablet, laptop, or a FIDO hardware security key

Knowledge Factor: PIN code (optional, may be used in place of an inherence factor)

Inherence Factor: fingerprint, iris, or faceprint (optional, may be used in place of a PIN code)

The FIDO protocols (U2F/CTAP1, CTAP2.x) and WebAuthn use asymmetric cryptography to authenticate users on external hardware devices (e.g., security keys) and platform authenticators built into laptops, tablets, and phones.  Authentication credentials are scoped to origins controlled by the relying party; relying parties cannot discover credentials for unrelated origins to protect privacy. ²¹ The credentials may be bound to a single device, as with hardware keys and some platform authenticators, or synchronized across a cloud fabric, ensuring availability across the user’s devices. FIDO credentials are considered to be highly phishing resistant.

Some FIDO credentials are attestable.  At registration, the authenticator emits a signed attestation statement identifying the provenance of the authenticator.  Relying parties can validate the signature on the attestation and collect additional authenticator metadata through the FIDO Metadata Service (MDS). ²² This data may include information about the authenticator’s certification level and conformance to standards such as FIPS140-1. ²³

Implementers should note that not all FIDO credentials are created equally. FIDO credentials may be created and managed entirely in software, within TPMs, Secure Enclaves, or other hardware embedded in general-purpose computers, phones, and tablets, or on hardware security keys. While all of these credentials use the same cryptographic primitives and protocols, relying parties should have an understanding of the differences between FIDO authentication mechanisms to help them make effective choices when implementing FIDO solutions.

• Passkeys are discoverable credentials that reside on the system that created them.

• Passkeys may be used as a highly phishing-resistant, single-factor credential, replacing passwords.

• The number of passkeys that can be configured on a single hardware security key is limited by the properties of the hardware and credentials.

• Passkeys created on hardware security keys do not leave the device.

• Passkeys may be synchronized across a fabric provided by platforms (Apple, Google, Microsoft) or password managers (1Password, Dashlane). Synchronization fabrics are provider-specific. Synchronized keys are sometimes called “multi-device credentials”. Non-synchronized keys are “single-device credentials”.

• Passkeys cannot be synchronized across providers.

• Synchronized credentials create an alternative credential recovery pathway. Credential recovery mechanisms are provider-specific.

• Passkeys may be shared by exporting them to nearby contacts through the AirDrop protocol on Apple platform devices.

• Passkeys, like all FIDO credentials, may not carry an attestation during registration. Relying parties may request attestation during credential registration. Authenticators and browsers may restrict whether an attestation is returned.

• In the event that a credential does not meet the relying party’s requirements, the RP must reject credential registration after the credential is created on the authenticator.

• Relying parties cannot be assured of the origin or security properties of unattested credentials. High-assurance use cases should require and validate all attestations.

The breadth of the FIDO2/WebAuthn ecosystem is too broad for this article.  Look for a future BoK article on the FIDO protocols to address these protocols in more depth.

Push-Based Authentication

Possession Factor: Access to the mobile device where the push notification is sent

Knowledge Factor: PIN or Password (optional)

Inherence Factor: Biometric on the device (optional)

Push-based authentication is primarily a mobile-based experience. At authentication time, the service sends a push notification to the user’s registered device(s) or applications.  The user receives the notification and may approve or decline the request.  As with most technologies, this has been abused by malicious actors who use social engineering or prompt bombing attacks to obtain the user's help to complete the authentication process. ²⁴ These attacks can be mitigated by providing additional context data to the user, such as the location of the authentication session or device identity, or requiring the user to copy a number from the push notification to the device attempting authentication. ²⁵

Smart Cards

Possession Factor: Smart Card

Knowledge Factor: PIN (optional, may use inherence factors)

Inherence Factor: Fingerprint (optional, may use PIN)

Smart Cards are physical devices of varying sizes (e.g., nano-SIM, SIM, credit card form factors) used to store a credential, often in the form of a cryptographic certificate, which can be unlocked by the user presenting a PIN or inherence factor to facilitate authentication.  The card may be presented by insertion into a physical reader or via a contactless protocol, such as NFC.

Smart cards exist in a wide variety of formats with different use cases depending on the industry in which they are used.  A common deployment is the use of a Common Access Card (CAC) by the US Federal Government.  After identity proofing, the federal government issues a CAC to an individual as both a physical identity document used to access government property, as well as a multi-factor authenticator.  Upon inserting the CAC into a reader, the user enters a PIN to unlock the device.  Once unlocked, the CAC authenticates the user against a directory service via the public key certificate embedded in the hardware.

Threat Mitigation by MFA Mechanism

The NIST Special Publication 800-63B is a recommended read as it provides an informative section on the various threat and security considerations and how to mitigate them. In this section, we highlight a subset of threats against MFA mechanisms and whether the mechanism is susceptible to the threat (❌), partially mitigates the threat (～), or completely mitigates the threat (✅).

The threats considered below are:

• Credential duplication - Can the credential be duplicated and used in a manner undetectable to the owner?  For example, a grid card could be photographed and used illicitly if the password was known, but the attack is not scalable.

• Eavesdropping / Man in the Middle - Active or passive eavesdropping of communications can compromise flows that depend on secrets, either by sniffing the secret off the wire as they are being delivered to the recipient (e.g., attacks on mobile SMS networks or SIM swapping), or by replaying secrets obtained through phishing.

• Replay - Some MFA mechanisms are designed for one-time use.  Implementations may fail to enforce one-time use of these secrets, allowing sniffed secrets to be replayed.

• Social Engineering - Manipulating a target through psychological means such as authority, intimidation, urgency, and other mechanisms to force a victim to take actions that may not be in their own best interests.  In the realm of MFA, this may be seen through attacks such as prompt bombing.

• Phishing - A form of social engineering where the victim is enticed into entering their credentials into a fraudulent site designed to look like a legitimate service.  Phishers will collect credentials, including passwords and second factors, and use them immediately to authenticate to the legitimate site to further their schemes.  In 2020, phishing was the most frequent crime reported to the FBI Internet Crime Complaint Center (IC3), representing almost one-third of all complaints (241,343 of 791,790). ²⁶

Conclusion

Using MFA is now considered an essential security best practice. It protects against many cyber threats, and the user experience has significantly improved since the early days of heavy hardware tokens. There is more to learn when it comes to deploying MFA in an environment; we suggest further exploring this space by reading Nishant Kaushik’s “Designing MFA for Humans” . ²⁷