Securing Passkeys: Thwarting Authentication Method Redaction Attacks

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

Introduction

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.

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.

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:

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

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:

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:

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.

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.

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:

• Most users just aren’t familiar enough with passkeys yet
• Implementers may not be aware of how AitM can modify the login view
• Account recovery, when a passkey is lost, is difficult without relying on less-secure methods

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:

• Password
  • Vulnerable to AitM since the password is entered in the attacker-controlled flow
• Security questions
  • Vulnerable to AitM and may allow for follow-on attacks on other accounts using the same questions
• Push notification to trusted devices
  • Vulnerable to AitM since it authenticates the existing attacker-controlled session
• Code over SMS/Phone/Email/Authenticator app or stored backup code
  • Vulnerable to AitM since the code is entered in the attacker-controlled flow
• Social/trusted contacts recovery
  • Can thwart AitM if recovery is done in a new session, but cumbersome and only works for large-scale social media accounts
• KYC/document verification
  • Cumbersome, but can thwart AitM if recovery is done in a new session - but if not, it could give the attacker access to your uploaded docs and let them recover your account themselves as well as facilitate identity theft elsewhere
• Magic link over pre-defined Email/SMS number
  • Can thwart AitM, if the link authenticates a new session, not the existing attacker-controlled session (See more details regarding Magic Links below).
• A second passkey/FIDO2 hardware key
  • Most secure method

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.

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:

• Design the authentication/account recovery flow with a full understanding of how AitM attacks operate
• Assume every login session is AitM-compromised and work to ensure that any attempt to downgrade the authentication method, away from passkeys, must “break out” of the existing session before continuing
• Red team your authentication flow design, using tools like Evilginx, to identify weaknesses
• Encourage or require users to add multiple passkeys, so that losing one doesn’t block access to the account or require a fallback to less-secure authentication methods
• Provide an option for users to go passwordless when they have a minimum number of passkeys registered
• Consult a user experience (UX) expert to understand how to minimize friction in the user experience of the login and account recovery process and balance it with security
• Consider a 2nd passkey as an alternative authentication method
• Utilize Microsoft Entra ID Protection or another provider of User and Entity Behavior Analytics (UEBA) to detect and automatically respond to the use of phished credentials, coupled with 24x7 monitoring and incident response by a Managed Detection and Response (MDR) service to ensure continuous protection and rapid threat mitigation.

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.