What We Do
How We Do
Get Started

Securing Passkeys: Thwarting Authentication Method Redaction Attacks

BY Joe Stewart

June 27, 2024 | 11 MINS READ

Want to learn more on how to achieve Cyber Resilience?

Protect your critical information from Authentication Method Redaction (AMR) attacks.


In the past year, the uptake of passkeys has surged, with industry giants such as Apple, Microsoft and Google championing their adoption. Joe Stewart, Principal Security Researcher with eSentire’s Threat Response Unit (TRU), has been reviewing many of the leading software providers’ implementation of passkey technology and their current “authentication process.”

Regrettably, Stewart found that cybercriminals can still break into accounts protected by passkey technology on many online platforms, such as banking, e-commerce, social media, website domain name administration, software development platforms and cloud accounts, by using Adversary-in-the-Middle (AitM) phishing attacks.

Stewart explains in this blog how passkeys are designed to work, how threat actors can currently circumvent passkey security, and the steps that online software providers and websites, that use or intend to use passkey technology, must take to ensure that their passkey implementation is secure from threat actors.

Passkeys—What are they?

So, what is a passkey exactly? A passkey is a virtual form of the FIDO2 hardware security keys, like the Yubikey. They both securely store a private key that can cryptographically sign a challenge, from a website, to prove your identity. The difference is that with passkeys, the private key can now be stored in your computer or mobile device, using a secure hardware enclave or password manager.

In addition to being both convenient and more secure, than easily stolen or guessed passwords, passkeys serve as a safeguard against AitM phishing attacks (if they are implemented correctly). This is because passkeys not only authenticate the user to the website, but they also authenticate the website to the user.

Passkeys are built upon the WebAuthn protocol - a core component of the FIDO2 standard that hardware security keys rely upon. Given that passkeys and hardware security keys share a common foundation in WebAuthn and considering that the term “passkey” is becoming increasingly familiar to end-users, we’ll use this term, throughout the blog, to mean any kind of WebAuthn/FIDO2-based authenticator for simplicity.

Passkeys: You’re Doing it Wrong

The benefits to using passkeys are clear – not only do they offer superior security and convenience over passwords, but they can also provide protection against the newest phishing methods that bypass first-generation, multi-factor authentication methods using the AitM approach.

The operative word here though is “can” because in reviewing the implementation of several of the most popular software service’s passkey authentication flow, nearly all of them can still be bypassed by AitM phishing, using authentication method redaction attacks. This is because most website passkey implementations still offer less-secure backup authentication methods, even when a passkey has been added to the account.

Since the AitM can manipulate the view presented to the user by modifying HTML, CSS and images or JavaScript in the login page, as it is proxied through to the end user, they can control the authentication flow and remove all references to passkey authentication. In the case where passkeys are used as a first-factor authentication method only, the downgraded authentication flow is now vulnerable to AitM. The graphic below shows a typical login-flow with and without an authentication method redaction attack in play.

This graphic shows a typical login-flow with and without an Authentication Method Redaction Attack in play.

An Example of a Passkey Attack against a Popular Software Service: Github

To demonstrate, we used the open-source Evilginx AitM software to simulate a phishing attack against Github. Evilginx uses site-specific configuration files called “phishlets” to define the behavior of the Evilginx proxy.

This graphic shows how we used the open source Evilginx AitM software to simulate a phishing attack against Github

In this case, we used the standard Github phishlet that can be found in various user repositories on Github itself. When the targeted user visits the lure URL, other than the hostname in the URL bar, what they will see looks just like the normal Github login page, because it is the actual Github login page, just proxied through Evilginx:

An image of the normal Github login page, which is proxied through Evilginx, shown to unsuspecting users

However, with a slight change to the standard phishlet configuration, we can force removal of the “Sign in with a passkey” text:

An image of the Github login page with the ‘Sign in with a passkey’ text removed

Unless the user specifically remembers that they should see a passkey option, they will most likely simply enter their username and password, which will be sent to the attacker along with the authentication token/cookies, which the attacker can use to maintain persistent access to the account.

In the case where passkeys are used as a second factor, things can become slightly harder for the attacker, but not if one or more fallback methods are offered:

An image of the Github two-factor authentication page

Here again, it would be trivial for the attacker to re-write the HTML of the page to delete the passkey authentication method, and/or use injected JavaScript to click on one of the alternate methods, jumping forward in the authentication flow automatically so that the user isn’t even aware there was a choice. Since second-factor methods, such as an authenticator app or recovery code are not AitM-resistant, the attacker will once again be able to capture all credentials and tokens/cookies they require to access the account.

It's also important to keep in mind that if the passkey is used as the second factor, then an AitM attacker will have already captured, at the very least, the username, phone number or email address of the victim, and additionally in most websites we looked at, the password of the victim.

Depending on the authentication flow, they might be prevented from continuing to authenticate to the target site. However, having the password for the account may allow for password-spray attacks against other websites the victim has an account on, which is another reason passwords should always be complex and unique per website.

And, if the passkey for the website is ever removed from the user’s account and no other authentication factor replaces it, the original account may now be vulnerable to takeover by the attacker at a later date.

Numerous Software Providers and Online Retailers have Flawed Passkey Implementations

Github is not the only example of flawed passkey implementation. Most passkey implementations we found listed on https://passkeys.directory/ were also vulnerable to similar authentication method redaction attacks. For example, when logging into a personal account, Microsoft also offers passkeys as a login option if you click the “Sign-in options” link at the bottom of the page:

An image of the Microsoft login page
An image of Microsoft’s sign in options offering passkeys as a method to login

However, if that link is hidden by the AitM proxy, the usual username+password flow is all the user will see and they are at risk of having those credentials stolen by the attacker if they proceed. But Microsoft has introduced a new “passwordless” option for consumer accounts – which “could” theoretically negate this style of attack.

An image of Microsoft’s paswordless account option for consumer accounts

Unfortunately, instead of allowing the user to log in with the passkey alone, the passwordless account option from Microsoft requires the use of the Microsoft Authenticator application as the sole method of identity verification, and this flow is still vulnerable to AitM attacks since it authenticates the attacker-controlled session.

However, enterprise users of Microsoft’s Entra ID (formerly known as Azure AD) and Intune products can still defend against AitM attacks with properly implemented Conditional Access policies, such as enforcing device login from “domain-joined, policy-compliant, managed devices” only.

Enterprise Identity and Access Management (IAM) solutions tend to be more flexible in terms of letting the tenant administrator define the login and account recovery flow for the organization, groups or individual users. When this is the case, it may be possible to define a secure, passwordless login flow using passkeys, that isn’t vulnerable to authentication method redaction attacks.

We were pleased to see that the open-source Keycloak IAM software has this capability, hopefully setting a benchmark for subscription-based Infrastructure-as-a-Service (IaaS) solutions to follow.

An image of the Keycloak IAM software offering users secure, passwordless login flow using passkeys

The reason that authentication method redaction attacks are possible isn’t necessarily a technical failure, in the sense that it’s a bug, but rather:

If it weren’t for the need for account recovery, an AitM-resistant passkey authentication flow could be fairly straightforward, abandoning passwords alogether in favor of passkeys. Unfortunately, we live in the real world and passkeys will be inevitably lost due to device loss/reset. As a partial solution, passkeys can be managed by a password manager, which offers greater resilience against loss, and yet the tradeoff is that the security of the password manager vault, itself, is now dependent on a master password and a second secret code at best.

Current Backup Verification Methods:

Recommendations—How to Secure Passkeys Effectively

Obviously, having multiple passkeys is the direction we should steer computer users, especially if at least one is a hardware key safely stored and secured by a PIN. But given that passkey adoption is still early, of the remaining methods, the magic link is probably the most secure method to recover an account in the case of passkey/security key loss or AitM authentication flow manipulation.

Of course, it means the account you are logging into is only as secure as your email inbox or the SMS network, which is “not very,” so extra security layers should be involved in the use of these links (e.g. randomly-generated one-time link with short timeout, login from previously authenticated IP addresses only, security questions or backup code entry in this session outside of AitM control).

To enhance the security of using magic links as a fallback authentication method for passkeys, we propose the concept of “warded links.” This new term, coined to signify a higher level of protection, implies that the magic link is fortified with additional security measures.

A warded link ensures that after the user clicks the link received via email, they are presented with a new secure authentication flow, isolated from any existing AitM-compromised session. This new flow also requests passkey authentication if the user account has it enabled, or the user can select from alternative MFA methods such as a mobile authenticator or code via email if a passkey is unavailable.

An image of the passkey authentication flow with a warded link fallback to protect accounts against unauthorized access

By implementing warded links, the security of the fallback authentication process is significantly bolstered, protecting the account against unauthorized access even if the attacker gains read access to the user’s inbox.

In short, currently there is no “perfect” combination of recovery method that satisfies the requirements of being AitM-resistant, secure against other attack vectors, while at the same time providing as little friction as possible to the user experience. Perhaps such a solution will be invented in the future, but for now, the best we can do is recommend some best practices for architecting authentication and account recovery flow using passkeys:

If you are not currently engaged with a Managed Detection and Response (MDR) provider, we highly recommend you partner with us for security services to disrupt threats before they impact your business. Want to learn more? Connect with an eSentire Security Specialist.

Joe Stewart
Joe Stewart Principal Security Researcher

Joe Stewart is a Principal Security Researcher with eSentire’s Threat Response Unit (TRU). As one of the industry’s leading security researchers, Stewart uncovered many of the top cyberthreats that have emerged in the past twenty years, as detailed in the books Fatal System Error by award-winning, Washington Post reporter Joseph Menn and Zero Day Threat by award-winning, former USA Today reporter, Byron Acohido. Stewart’s research has also appeared on the cover of Businessweek, in the Wall Street Journal, on 60 Minutes, and in the top cybersecurity publications globally. 

While with eSentire, Stewart’s research has been featured in Forbes, Wired and numerous other business and security media outlets. Prior to joining eSentire, Stewart spent 17 years as Director of Malware Research for Secureworks, a cybersecurity division of Dell. He has also served as Principal Threat Researcher with PhishLabs, a cyber threat intelligence company, now part of Fortra.

Read the Latest from eSentire