In an earlier post, we discussed the Federal zero-trust architecture (ZTA) strategy that the United States government is employing to improve cybersecurity in 2024 & beyond. One of the five pillars of ZTA is the Identity pillar (figure 1), which requires that US agencies use phishing–resistant Multi-Factor Authentication (phishing-resistant MFA) methods to protect their personnel from sophisticated on-line attacks.
Let’s look at what it means to implement phishing–resistant MFA & what phishing-resistant MFA could look like in an IBM i environment.
How Phishing undermines Multi-Factor Authentication
Multi-Factor Authentication (MFA) provides user login security by helping ensure that the person signing on with a specific user ID and password is actually the person who owns that user ID and password. Traditional MFA verification requires that users present two or more independent pieces of authentication credentials (MFA verification factors, shown in figure 2) confirming their identity before they can access a digital resource, such as an IBM i server. For more information on IBM i MFA, see our previous post Multi-Factor Authentication Provides IBM i User Login Security & Compliance.
However, MFA verification factors can be stolen using phishing attacks. Phishing attacks can dynamically interact with and fool the user into revealing one or more verification factors, which the attacker can leverage to log in as an MFA user. MFA verification factors can be disclosed by social engineering, Man-in-the-Middle (MiTM) attacks, MFA bombing, MFA fatigue, vishing, smishing, pharming and many other phishing schemes.
Common cybersecurity statistics usually state that 80% (or more) of cyberattacks begin with a phishing scheme, including MFA attacks. While MFA protects user logins, MFA is not an airtight defensive system against unauthorized logins enabled by phishing schemes.
What is Phishing-resistant MFA?
Phishing-resistant MFA protects Multi-Factor Authentication configurations from attempts to compromise the MFA authentication process through phishing attacks. Phishing-resistant MFA processes are immune to attackers intercepting or tricking users into revealing system access information. Users and providers must provide trusted proof of their identity (they are who they say they are). Users must also prove intent that they initiated the access request instead of an attacker (user intent).
As shown in figure 3, the four core elements needed for phishing-resistant MFA are:
- Establish Strong Binding: Strong binding (trust relationship) must be built up between user and provider. Strong binding can occur through cryptographic registration for an authenticator—which can include a phishing-resistant security key, a Personal Identity Verification (PIV) smartcard or a Common Access Card (CAC) possessed by the user—and an Identity Provider service (IdP) that verifies user identities. This enables your authenticator to identify fake websites or other entities phishing for login information and establishes an MFA verification factor in the Possession category (something you have).
- Elimination of shared secrets: Phishing-resistant MFA calls for the elimination of shared secrets, including user passwords, API keys, or other credentials. Strong binding allows for using asymmetric cryptography (aka, public-private key cryptography). Asymmetric cryptography uses a public-private keypair that must be used for each authentication. To enable phishing-resistant MFA, the private key must be safely stored inside a tamper-proof authenticator such as a hardware security key, PIV smartcard or CAC as mentioned above. Attackers will be unable to authenticate to the requested system without having physical possession of the authentication device. Cryptography replaces the need for using a shared secret for authentication.
- Only respond to trusted parties: Phishing schemes frequently fool a target user into sharing their credentials via continuous push notifications, SMS or OTP codes, fake Websites, social engineering & more. Phishing-resistant MFA must negate these types of verifier impersonation attacks by responding to valid requests only from known & trusted parties. Building a trust relationship for authentication and employing asymmetric cryptography based on items that cannot be phished help satisfy this requirement.
- User intent: Phishing-resistant MFA must demonstrate the active involvement of the user in initiating and authorizing a login action. Active involvement must be clearly understood by the user and not part of a phishing scheme such as a push notification attack. User intent must be established by prompting the user to perform an action that confirms the user’s active involvement in the authentication process. Examples might include pressing a button, touching a key, biometric checks (fingerprints, facial recognition, etc.) on the trusted device or other actions that prompt the user to complete authentication. User intent can establish an MFA verification factor in the Inherence category (something you are), Possession category (something you have) or as a Behavioral verification factor (something you do).
When an MFA implementation satisfies these four elements, it becomes phishing-resistant MFA.
Phishing-resistant MFA & IBM i
What should you look for if you need to implement phishing-resistant MFA on the IBM i?
Organizations implementing phishing-resistant MFA as part of the United States Government zero trust architecture (ZTA) strategy, should start by referencing the Multi-Factor Authentication section of the Federal Zero Trust Strategy Web site to obtain more information on ZTA-related MFA strategies and requirements.
Also note that there are no native IBM i capabilities for traditional MFA or phishing-resistant MFA. Anyone interested in IBM i phishing-resistant MFA will need to evaluate third-party MFA solutions that support the four elements of phishing-resistant MFA outlined above. MFA solutions may support and interface with several of the following or other capabilities to implement IBM i phishing-resistant MFA.
Certificate-based authentication (CBA)
Verifies user identity through trusted digital certificates. CBA certificates can function as electronic passwords or files. Uses cryptography and public key infrastructure. CBAs are often used in banking applications.
Common Access Card (CAC) smart cards
A CAC is an identity card for active-duty US military personnel, Selected Reserve, Department of Defense (DoD) civilian employees and eligible contractor personnel. CACs meets smart card standards in line with United States government Homeland Security Presidential Directive 12 (HSPD-12) and Federal Information Processing Standards (FIPS) 201-3 specifications. Contains identity credentials for identity assurance, authenticator assurance and to grant access to DoD resources.
FIDO2/Web Authentication (WebAuthn)
FIDO2 is a widely used phishing resistant authentication standard. It uses public key cryptography for authentication (Possession MFA category), instead of using shared secrets such as passwords and SMS OTP (Knowledge MFA category). FIDO2 is a joint project of the FIDO Alliance and the World Wide Web Consortium (W3C).
FIDO2 uses the W3C Web Authentication (WebAuthn) specification and its own Client-to-Authenticator Protocol (CTAP) for authentication. It uses common devices to perform authentication in desktop and mobile environments. FIDO2 authentication methods include biometric-capable devices, platform authenticators and roaming authenticators/security keys.
Personal Identity Verification (PIV) card
A PIV is an identity card or smartcard that contains identity credentials for identity assurance, authenticator assurance and personal vetting assurance. Widely used in the US government for civilian identification, the Federal Office of Management and Budget requires the use of “…PIV credentials as the “primary” means of authentication to Federal Information Systems…” as stated in the Federal Zero Trust Strategy.
Derived Personal Identity Verification (PIV)
A credential issued based on proof of possession and control of a PIV Card. Derived PIV credentials are used in situations where a physical PIV card cannot be used.
Public Key Infrastructure (PKI)
The Public Key Infrastructure (PKI) is the set of technologies, processes and procedures that are used to create, manage, distribute, use, store and revoke public–keys & digital certificates. PKI underlies the framework that enables encryption, digital signatures and other security technologies across the Internet. For phishing-resistant MFA, public key infrastructure along with matching private keys, protects and authenticates communication between servers and clients. PKI is also used for secure communications.
The challenge of IBM i Phishing-resistant MFA
Implementing IBM i phishing-resistant MFA will be challenging. Establishing strong binding calls for local trusted physical or device-based credentials that are unique to users and devices. Eliminating shared secrets will move IBM i shops away from requiring shared secrets for user logins (including user IDs & passwords, SMS OTPs and possibly authenticator apps). User intent requirements will force the use of local device actions to complete an MFA login.
Today’s blog post introduced you to phishing-resistant MFA and what’s required to make an MFA implementation immune to phishing attacks. If you would like to learn more about Multi-Factor authentication on the IBM i or to discuss IBM i MFA options, please feel free to contact SEA.
