BLOG POST

In the era of ever-evolving cybersecurity threats, Multi-Factor Authentication (MFA) has emerged as a hallmark of robust user authentication. While the premise of MFA is straightforward, implementation nuances can introduce significant complexities, especially when aligning with Payment Card Industry (PCI) guidelines. The distinction PCI makes between multi-factor and multi-step authentication (MSA) presses developers into a challenging trilemma. This article explores this trilemma, the real-world MFA practices of major internet platforms, and the pitfalls in the PCI guidance.

MFA Trilemma Explored

We're familiar with the concept of trade-offs. These have been thoroughly conveyed to us through the Security Usability Triangle and various "pick-two" internet memes. We are likewise familiar with the trade-offs of using MFA over standard single-factor authentication. These include additional complexity and user support, and more friction in the authentication process for the benefit of greatly enhanced security.

In 2017, the PCI Security Standards Council released an information supplement on Multi-Factor Authentication. In this document, and a subsequent FAQ, the Council clarifies that MFA, by their definition, requires verifying all authentication factors together, instead of in separate steps.

This difference seems small--merely an implementation detail. However, when you go through the process of designing a system for actual users, difficulties arise. We summarize the desirable characteristics of such a system, which includes the PCI required "Joint Verification of Factors" in the following MFA Trilemma™.

Choose Two:

1. User Enumeration Prevention: By only disclosing accounts after successful authentication, attackers are prevented from discovering valid user accounts on a system. To maintain this prevention, it's essential to design error messages that do not inadvertently reveal information about the existence or non-existence of accounts.

2. Support for Multiple Second Factors: Users value options. By offering a variety of second-factor authentication methods, such as security keys, SMS or push notifications, and hardware tokens, both user convenience and security are enhanced.

3. Joint Verification of Factors: Security is enhanced by only providing authentication feedback once all authentication factors have been provided. This approach safeguards against attacks targeting individual authentication factors sequentially.

Real-World MFA Practices

While we call it the MFA Trilemma, it is technically possible to support all three properties in an application, it is just extremely rare. That is because achieving all three properties introduces unintended consequences--negative trade-offs that are generally not worth it.

To demonstrate this, we'll review the implementation details of two internet giants that take security very seriously. One application's MFA implementation is PCI compliant while the other is not. However, both opted to choose two from the MFA Trilemma rather than live with the consequences of achieving all three

Amazon Web Services (AWS)

Trilemma Choices:

• Support for Multiple Second Factors
• Joint Verification of Factors

The AWS authentication page initially prompts the user for an Account ID, username, and password. If the user account submitted on this page uses single factor authentication, the application provides immediate feedback on whether authentication succeeded. The application does not leak whether the username or the password was incorrect.

If, however, the user account is configured for MFA, the authentication process transitions to a second page which prompts the user for the next factor from among those configured for the account. This page is reached whether or not the user's password is correct and they are not provided with authentication feedback until after the second factor is presented.

This approach, while it maintains convenience, does not prevent user enumeration among user accounts with MFA enabled. Another consequence of this design, while not included in our trilemma, is that for a known username, an attacker is able to determine if MFA is enabled or not. While this does not weaken accounts with MFA enabled, it could increase targeting of single factor accounts.

GitHub

Trilemma Choices:

• Supports for Multiple Second Factors
• User Enumeration Prevention

GitHub takes a more standard approach to MFA by using a multi-step process. The application always starts by prompting the user for their username and password. The application then provides immediate feedback on whether authentication succeeded but does not leak whether the username or the password was incorrect. If the user is configured for single factor authentication, access is then granted.

Note that GitHub started enforcing MFA on accounts that contribute code to any project on the platform on September 21st, 2023.

For users with MFA enabled, once the username and password have been submitted the authentication process transitions to a second page which prompts the user for the next factor from among those configured for the account.

This approach does not meet PCI guidance because it does not validate all factors before giving authentication feedback. However it allows non-leaky error messages to be provided to users in the case of an incorrect username or password.

Unintended Consequences

The more stringent the design requirements, the more tradeoffs you must accept. Here we present some of the compromises you might need to make in order to achieve joint verification of factors.

Additional Support Costs:

MFA implementations that use a password in addition to a second factor generally include a reset process for the password. Since both factors are evaluated together, if authentication fails, the user will not know which of their factors caused the error. This introduces increased friction and confusion and may result in more users contacting the helpdesk rather than using the self-help option to reset their password.

Operational Intricacies:

For certain authentication methods like FIDO2, which operate on a challenge-response mechanism, joint verification of factors introduces a complex dilemma. If the primary factor is incorrect, the system would need to present dummy data to proceed to the next factor. This not only complicates the backend process but also can lead to user confusion. Users may assume that their password is correct because they advanced to the second authentication step, which is not the case.

Compromised Usability:

To choose all three MFA Trilemma properties, the authentication process must appear identical for all users. This would require a user to select their second factor from among those supported, not from among those they have configured, otherwise it could disclose a user account.

Risk of User Harassment:

When the system is designed to trigger second-factor alerts (like SMS or push notifications) before validating the primary factor, malicious actors can exploit it with only knowledge of the username. Unsuspecting users might be inundated with unsolicited authentication prompts or even incur costs from unwanted SMS messages. This can lead to user distrust, undermining the very security MFA aims to bolster.

Note that AWS's design should suffer from this deficiency; they prevent it by only supporting non-alert MFA options, such as security keys and hardware tokens.

Continued Risk of Timing Attacks:

The process of validating a password is vulnerable to timing attacks. Because of this, application code must use a constant-time comparison function to evaluate if a password is correct. When performing joint verification of factors, the same attack can be used to determine whether or not a password is correct, defeating the whole point of performing joint verification.

To mitigate this, the process of validating both factors must be constant-time.

All of these A system with a single type of second factor that is also mandatory eliminates most of the trade-offs. However, this system comes with greatly reduced usability.

Ideal Conditions

I believe the PCI guidance was drafted primarily with system-level access in mind. In this scenario, the systems in question would be owned by an organization and the system users would be employees or contractors. Under these ideal conditions, the organization has control over both the infrastructure and the user environment. This means that they can enforce security policies uniformly, ensure proper training for users, and have direct channels of communication to handle any authentication issues. More importantly, they have the capability of issuing and enforcing use of a single type of second factor.

For this type of access, user account enumeration is also not an expectation. With two of the three MFA Trilemma choices now unneeded, a compliant implementation is now much easier and comes with many fewer tradeoffs.

Unfortunately, public web applications with a diverse user base will need more flexibility.

PCI's Redefined Terminology

The PCI Multi-Factor Authentication guidance document clarifies PCI's requirements for MFA but muddies some definitions in the process. In my research, I was unable to find another authoritative source that defines MFA as requiring all factors to be verified before an authorization decision is made.

NIST's SP 800-172A, for example, describes MFA as "Authentication using two or more different factors to achieve authentication." There is no mention of joint validation.

The term 'multi-step authentication' (MSA) is frequently used, especially in security standards, but is generally understood to refer to an authentication process that consists of two or more steps or pages. When used in this context, it is mutually exclusive from MFA; an authentication process can be multi-step, multi-factor, neither, or both.

PCI's approach of trying to redefine these well-understood terms, rather than introducing a new term to capture their specific requirement, is perplexing. A more fitting approach would have been to introduce a term like Simultaneous Multi-Factor Authentication (SMFA). Not only does this give some indication of the enhanced nature of the authentication process, it also avoids the confusion of redefining established terms.

Conclusion

PCI has provided a clear definition of MFA since 2017. However, application providers, especially those with a substantial real-world user base, find themselves navigating through the inevitable trade-offs arising from this stringent definition. While it would be advantageous for organizations to employ a risk-based approach, selecting from real-world security impacts that counterbalance each other, this alternative is currently not available.