The Need for Phishing-Resistant Multi-Factor Authentication

This blog post is the first in a series of posts that focus on the growing incidence of credential phishing and how Okta can help organizations of all sizes in implementing phishing-resistant multi-factor authentication.

Credential phishing, the practice of tricking users into revealing sensitive personal information such as authentication credentials for a business application, is one of the most prevalent forms of identity-based attacks on the web today. Security companies and adversaries continue to play a cat-and-mouse game in which new security techniques are countered by newer and more ingenious attack vectors. 

For instance, signature-based email security tools that rely on scanning several elements such as sender address, subject, copy, and signature are being bypassed by polymorphic phishing—an attack technique that relies on changing these elements constantly to evade detection. 

Detection mechanisms that identify fake or spoofed domains by examining whether or not they use TLS certificates are being thwarted by malicious actors who set up fake domains that use HTTPS via free TLS certificate providers such as LetsEncrypt.  

Organizations using Multi-Factor Authentication (MFA) as an added security measure report a rise in MFA-specific phishing attacks that have evolved to target not just the first but also the second factor. 

Most organizations are investing more in user awareness and training users to spot phishing messages and identify fake domains. However, given the prevalence of sophisticated techniques in modern attacks (registering domains with Cyrillic letters instead of regular ones, for instance), it’s extremely likely that some employees will fall for the attack and click the links to the malicious domain. 

This blog post focuses specifically on the significance of phishing-resistant MFA as a countermeasure to rising sophistication in phishing attacks and underscores the importance of hardening traditional two-factor authentication (2FA) mechanisms to make them phishing-resistant by using authenticators with higher assurance levels.

How modern credential phishing attacks work: the adversary in the middle

In the past, credential phishing attacks followed a trend—adversaries would recreate static, HTML templates of login pages for mission-critical applications, send links to these fake pages to victims, and log the credentials entered, either for mounting personal attacks or selling on the dark web. 2FA was able to block such attacks with an SMS-based OTP, for instance, which would then thwart the attack. 

But in the recent wave of sophisticated phishing attacks that Okta has observed, we’ve seen adversaries move away from static templates to reverse-proxy-based frameworks to set up a proxy between the real site and the fake site and mount real-time, adversary-in-the-middle (AiTM) attacks. These frameworks allow clients' requests to pass to another server. This lets the framework act as an AiTM agent, effectively intercepting all requests from clients, modifying and forwarding them to another server. It can then intercept the server's responses, modify them, and forward them back to clients. This setup allows threat actors to capture credentials sent with POST request packets and, upon successful sign-in, capture valid session cookies sent back from the proxied server, which can then be used for SSO into the real domain.

4B69cXertjrITy TyevdS7JWwKIr0wfkE4o8o4BNY84bVqABw9iai9vjsl5iu6GRewKqv0X8xwiFD XhPfIH4MmXy8uW15eDWRZlqC8dO fokzUNASpiHOaUfCtMTGEs0nHduz6hkimwsGcY4cMWhVhfNiplErHOgh62BXY sCOt3oWd8qd17OKrFA


One example of such a framework is Evilginx, an open-source tool freely available on the web. Evilginx is a standalone AiTM reverse proxy. It captures the credentials and session token from an MFA session and can then be used to replay the stolen credentials to bypass MFA. Here’s a stepwise example of how such an attack might work:


  1. The threat actor downloads and configures Evilginx–a reverse proxy attack framework for mounting AiTM attacks.
  2. The adversary sets up a fake domain and uses a free service such as LetsEncrypt—a free TLS certificate provider to portray the website as a legitimate and secure website.
  3. The adversary sends out a phishing message to the victim via email or text.
  4. The victim clicks on the phishing URL and is provided with the fake app login screen on the registered domain.
  5. The victim enters a password and is prompted for the second factor.
  6. The victim authenticates and Evilginx captures the session cookie that is generated after 2FA.
  7. The victim is redirected to the redirect URL and wonders why the auth didn’t work.
  8. The adversary has captured the credentials and session token and uses them to log in to the real website with an MFA bypass. Sensitive data and applications can now be compromised.

Traditional MFA and phishing-resistant MFA

It’s important to note that traditional 2FA/MFA still remains an effective form of protection against many forms of credential theft because: 

  • It limits what an adversary can do with a stolen password, and 
  • Creates numerous detection opportunities when an adversary attempts to bypass it,

However, these traditional mechanisms that rely on SMS—or email-based OTPs, push notifications, et al.—have one crucial gap; they cannot distinguish between a legitimate domain and a malicious domain. To do so, phishing-resistant MFA is crucial for preventing attacks such as the AiTM scenario outlined earlier. So, what exactly does phishing-resistant MFA involve, and how is it more secure than 2FA?

The National Institute of Standards and Technology (NIST) has published Special Publication 800-63B, which articulates technical requirements for federal agencies implementing digital identity services and helps define phishing-resistant MFA. The key phishing-resistance attributes identified in this publication include:

  • Verifier impersonation resistance using cryptographic binding between authenticator and user identity
  • Replay resistance via OTP devices, cryptographic authenticators, and look-up secrets
  • Verifier-compromise resistance by ensuring that any public keys stored by the verifier are associated with the use of approved cryptographic algorithms
  • Authentication intent that requires the user to explicitly respond to each authentication or re-authentication request 

In simple terms, for an MFA mechanism to be considered phishing-resistant to AiTM attacks, the authenticator used should be cryptographically bound to the domain and be able to distinguish between the real domain and the fake domain generated by the attacker. This way, the mechanism can immediately stop the attack so that the attacker cannot capture the credentials or session cookie and replay them. An authenticator is something an end user possesses and controls, such as a PIV Card, a password, a Yubikey, etc., and uses to authenticate to an account. 

The NIST publication also offers several useful guidelines for defining Authenticator Assurance Levels (AALs). These guidelines compare the strengths of different authenticators and provide tips on choosing authenticators with high degrees of resistance to phishing  and other forms of identity theft.

The table below provides an overview of the pros and cons of various authenticators supported by Okta with their assurance levels. 

Authenticator types supported by Okta 

Assurance level






  • Provides baseline security
    at a low cost
  • Easy to use and deploy
  • Users are familiar with the process of logging in with a password
  • Vulnerable to data breaches due to users' poor password management habits (use of common passwords, writing passwords down, reusing passwords, etc.)
  • Major risks from social engineering and phishing
  • Users tend to forget passwords when password requirements are too complex
  • Difficult to type on mobile devices


Security Question

  • Provides baseline security at a low cost
  • Users are familiar with the process of answering a security question during login
  • Users often forget their answers
  • Many questions are weak, making answers easy to guess
    or discover
  • Subject to social engineering
    and phishing


SMS, Voice, Email One-time Password (OTP)

  • Familiar experience for users, as many consumer apps already use OTP as a form of account/identity verification
  • Easy to deploy, as most individuals have a phone
  • Relies on phone/internet service provider for security; subject to social engineering (e.g. SIM swapping)
  • May require using a personal device, which cannot be enforced in some regions
  • Limited DMARC standard implementation means detecting email-based spoofing is difficult


Mobile/Desktop One-time Password (OTP) Apps


Examples: Okta Verify OTP, Google Authenticator, Authy

  • Low cost, many users able to install an app on laptop or phone
  • Algorithmically generated
  • Crypto-based security
  • Does not require internet/data service to use (i.e. airplanes, international travel)
  • Biometric verification can be set intrinsic to authentication
  • Limited protection against a stolen device
  • May require using a personal device, which cannot be enforced in some regions
  • Subject to real-time, man-in-the-middle attacks


Mobile app push notifications


Examples: Okta Verify with Push

  • Low cost; many users able to install an app on laptop or phone
  • Algorithmically generated; delivered over secure channels
  • Some apps support biometrics
  • User-friendly
  • May require using a personal mobile device–users may have privacy concerns and cannot be enforced in some regions
  • Subject to man-in-the-middle and phishing attacks


Physical token One-Time Password (OTP)


Examples:  Symantec VIP

  • Algorithmically generated
  • Does not require internet/data service to use
  • Does not require a personal phone/device
  • Subject to loss and may require a separate recovery option
  • Higher deployment and provisioning costs; orgs may not deploy to all users
  • Many OTP tokens do not support biometrics


Okta FastPass

  • Phishing-resistant for all managed devices and for MacOS, Windows, and Android on unmanaged devices
  • Seamless end user experience
  • Leverages the device context signals (some collected by Okta Verify itself and others through integration partners such as CrowdStrike and Tanium) to help administrators make policy decisions based on the device posture
  • Can reduce IT and support costs for factor enrollment and reset
  • Okta Verify (an MFA thin client) needs to be installed and users need to be enrolled 


FIDO 2 Platform authenticators ( Apple Passkeys, Mac Touch ID, Android fingerprint, Windows Hello)

and Passkeys 

  • Phishing-resistant
  • Seamless end user experience
  • Puts organizations on a path to passwordless
  • Can reduce IT and support costs for factor enrollment and reset
  • Cross-platform support is poor or emerging 
  • Credential backups to cloud can create security issues for organizations relying on device bound authenticators


Personal Identity Verification (PIV)/ Common Access Card (CAC) Smart Cards

  • Mature technology
  • Extremely strong authentication level
  • Phishing-resistant inbuilt MFA (required PIN to access) 
  • Needs an insert-based, contact-based reader; not contactless
  • Can be easily lost or stolen
  • Not widely supported on mobile platforms
  • PIN resets can be painful


FIDO 2.0

Hardware-based security keys Example: YubiKey 


  • Phishing-resistant
  • Cross-platform coverage
  • Seamless end user experience
  • Puts organizations on a path to passwordless
  • Can reduce IT and support costs for factor enrollment and reset
  • Not yet widely adopted
  • High initial cost because it may require purchasing new hardware


What if the attacker targets endpoints?  

Some phishing attacks rely on payloads that deliver malware or ransomware to take over accounts and devices and hijack credentials and sessions. To address such endpoint threats, Okta has partnered with leading endpoint protection and management providers like VMware and CrowdStrike. The integrations deliver device-risk signals into the Okta Identity Cloud to unlock more secure, seamless access across endpoint ecosystems. 

Okta’s credential-phishing-resistant capabilities 

Okta offers end-to-end, identity-centric, phishing-resistant authentication that supports all user personas, from business partners to an extended workforce, and works at scale for organizations. These include:

  • Phishing resistance with Okta FastPass (stay tuned for more exciting announcements on this at Oktane 2022)
  • Support for FIDO 2 standards with WebAuthn 
  • Support for PIV smart cards

Okta’s solutions integrate with any device management tool to enforce phishing-resistant authentication flows. Okta also offers support for adding device checks to authentication policy rules for admins to establish minimum requirements for the devices that have access to systems and applications in the organization. 

To learn more about how Okta’s solutions can help you protect and enable your employees, contractors, and partners, go to