Introduction

To address the US federal requirements of OMB M-22-09, phishing-resistant MFA is a requirement for organizations moving towards a zero trust architecture (ZTA). OMB M-22-09 identifies two types of phishing-resistant protocols: smart card (PIV) and FIDO2/WebAuthn. As attacks have evolved to bypass traditional MFA solutions, organizations and government agencies are mandating the use of modern, phishing-resistant MFA. With OMB M-22-09, the US government is requiring all agencies to use phishing-resistant MFA and strongly encourages the move to zero trust architecture (ZTA).

The YubiKey supports both types of phishing-resistant authentication and provides the most comprehensive authenticator solution available to help agencies and organizations protect their environments. Using a single multi-protocol device that bridges both legacy and modern applications/services increases security, usability and ultimately achieves compliance.

What is phishing-resistant MFA?

It is important to define what phishing-resistant multi-factor authentication (MFA) is, and for customers to understand the authentication options available to them. 

Phishing-resistant MFA refers to an authentication process that is immune to attackers intercepting or even tricking users into revealing access information. It requires each party to provide evidence of their identity, but also to communicate their intention to initiate through deliberate action. There are several components that help define what  phishing-resistant MFA is.

The following sections discuss the various components that should be considered.

Establish strong binding between authenticator and identity

To ensure there is high confidence that each party knows who the other is, an initial cryptographic registration process needs to occur that establishes a trust relationship. Initial registration can include an identity proofing process and should also include registering a user’s authenticator to establish the strong binding. In a legacy MFA approach, this initial registration would happen by sharing a secret such as a one-time passcode or SMS text code out of band with the idea that only the user and the authentication service would know the shared secret. However, this method is susceptible to phishing as the shared secret can easily be obtained by an attacker.

For the US federal government, PIV issuance includes an identity proofing process and includes registering a user’s authenticator (in most cases a PIV or CAC). To address the known weakness of a shared secret, phishing-resistant MFA leverages public key cryptography to establish a trust relationship between the user and a relying party. This ensures that future authentication sessions are occurring only between the authenticator that is registered and the relying party. The private key is the most important component in the trust relationship, making it vitally important to protect it at all times.

Eliminate shared secrets

Once a trust relationship is established, the authentication mechanism must be based on public key cryptography that is unique for every trust relationship. The registration or authentication process should not share secrets, but rely on an asymmetric cryptographic ceremony, i.e. without the private key, the authentication ceremony cannot be performed. The private key must be stored in hardware that can be attested and not be exportable to be truly secure.

Know the requesting party

In a phishable authentication scenario, attackers can effectively trick a person into sharing their sign-in credentials, or less-secure authentication factors such as SMS codes or OTP. Additionally, the attacker uses readily available techniques like building fake websites that replicate sites users are familiar with, social engineering or sending a large number of push notification requests with the goal to trick or overwhelm users to accept the authentication request. It is critical to use phishing-resistant MFA methods to address this issue by only responding to valid requests by known trusted parties that don't inconvenience users. Savvy attackers may attempt to inconvenience users to the point of frustration, because when a user is frustrated, they may forgo security measures that let attackers compromise MFA.

User Intent

Even though we don’t want to frustrate users, the users still need to be involved to authorize a login action. The user should clearly understand and authorize the authentication event, i.e. they need to be fully aware of what they are consenting to do. To not confuse the user, user authorization requests should only exist as part of an access request that the user initiated. Having users receive random and incessant SMS or Push notification requests can lead users into approving access that they are not aware of. The user action when coupled with public key cryptography also severely limits the rate of attacks and significantly reduces the attack surface.

With phishing-resistant MFA explained, you can more easily understand how different MFA options may meet or fall short of the phishing-resistant criteria. M-22-09 specifically states, “agency systems must discontinue support for authentication methods that fail to resist phishing, including protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications.” 

From the above set of phishing-resistant MFA criteria, two authentication standards have become the industry standard smart cards (PIV) and FIDO2/WebAuthn. Cryptography based on Public Key Infrastructure, where private key material resides within a hardware device, is the cornerstone of secure authentication systems. Both authentication standards meet the guidelines as described in OMB M-22-09 and provide phishing-resistant options. The YubiKey supports both the smart card (PIV) and FIDO2/WebAuthn protocols to deliver phishing-resistant MFA.

Considerations for implementation in Federal Government

Per OMB M-22-09, “Agencies must require their users to use a phishing-resistant method to access agency hosted accounts. For routine self-service access by agency staff, contractors, and partners, agency systems must discontinue support for authentication methods that fail to resist phishing, including protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications.” Today, this reference explicitly removes most software authenticator applications from inclusion to achieve any phishing-resistant solution, since they rely on mechanisms explicitly called out by the OMB as not suitable.

Implementation of phishing-resistant MFA for the federal government comes with additional criteria that needs to be considered and addressed. To meet the minimum US federal government requirements, the following requirements must be met:

• OMB M-22-09 specifies PIV and WebAuthn as the phishing-resistant protocols to use. 
• OMB M-19-17 and NIST SP800-157 require that PIV credentials need to be properly issued and managed as a primary or derived credential.
• A FIPS validated authenticator must be listed under CMVP.
• Solutions are generally available and are fully supported by the vendor.

Federal Information Processing Standard (FIPS)

It is also important to note that your deployment could be subject to additional requirements. As a case in point, if you are a US government agency or work with the government, you are required to use FIPS validated authenticators. The YubiKey 5 FIPS Series is FIPS 140-2 validated (Overall Level 1 and Level 2, Physical Security Level 3) enabling Yubico customers to meet the highest authenticator assurance level 3 (AAL3) of NIST SP800-63B guidance, which in turn will satisfy the authenticator requirements for OMB M-22-09 in a zero trust solution.

Authenticator Assurance Levels (AAL’s)

M-22-09’s MFA directives rely on NIST Special Publication 800-63B requirements. NIST SP 800-63B has three authentication levels with the middle and highest levels requiring phishing-resistant MFA. Most US federal agencies will require NIST AAL2 or AAL3, as AAL1 does not require any form of MFA. Additionally, the MFA authenticator must be FIPS 140 validated to achieve any AAL, proven by being listed on the Cryptographic Module Validation Program site. FIPS 140 validation indicates that the authenticator has met a set of specific standards to protect the cryptographic module appropriate for the Federal government. Authenticators that meet AAL3 must meet additional FIPS 140 requirements including physical security level 3. The best way to ensure you are leveraging a FIPS validated authenticator is to review the Cryptographic Module Validation Program site and look for the appropriate certificate such as that available for the YubiKey 5 FIPS Series.