Passkey Redaction Attacks Subvert GitHub, Microsoft Authentication

While online accounts are increasingly protected by passkey technology, it turns out that many banking, e-commerce, social media, website domain name administration, software development platforms, cloud accounts, and more can still be compromised using adversary-in-the-middle (AitM) attacks that make passkeys moot.

That's according to Joe Stewart, principal security researcher with eSentire's Threat Response Unit (TRU), who says the problem lies not in the passkeys themselves but in their implementation and the need for account recovery options.

Many websites provide less-secure backup authentication methods in the event a user has an issue with their passkey or a lost device, so that accounts don't become unrecoverable. Attackers can take advantage of this by simply inserting themselves between the user and the website as they would in any AitM scenario, then manipulating what the login screen looks like so that the user isn't given the passkey option at all.

"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," Stewart explained in a blog post on his findings, which he referred to as "authentication method redaction attacks."

Using this strategy, they can force a target to downgrade to a less-secure alternative that can be intercepted by the lurking adversary. And that's a discovery that "blows a hole" in the security conversation around passkeys, Stewart explains to Dark Reading.

"We started digging into it and found that some, if not all, of the passkey authentication mechanisms out there, have the same issue where they offer passkeys as one option of many, and that attackers can just simply remove that option, and you're left with the less secure methods that give them a wide-open door to account takeover," he says.

GitHub, Microsoft Passkey Implementations Susceptible to Attack

In one proof-of-concept (PoC) example of this attack flow, Stewart was able to use the open source Evilginx AitM software to proxy and alter an actual GitHub login page, removing the “Sign in with a passkey” text from the page so that a user wouldn't see it, and instead giving the option to choose a different way to sign in.

"Unless the user specifically remembers that they should see a passkey option, they will most likely simply choose to 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," Stewart says.

In another scenario where a passkey is used as a second factor of authentication, Stewart found that once again, it's trivial to rewrite the HTML of the page to delete the second-factor passkey authentication method altogether. Or, he explained in the findings, an attacker could "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."

As he wrote in the post, "since other 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."

Indeed, in a third scenario using a Microsoft consumer account, the passkey sign-in option can again be hidden. However, Microsoft has introduced a new “passwordless” option that could theoretically negate this style of attack. The bad news? It doesn't actually work to thwart passkey redaction, because the passwordless account option requires the use of the Microsoft Authenticator application as the sole method of identity verification — a flow that's still vulnerable to AitM attacks, Stewart explains.

As mentioned, GitHub and Microsoft are not alone; most large retailers and cloud app providers have the same issue.

Not a Vulnerability but a Sad Reality

Stewart stresses that authentication method redaction attacks succeed not because there are flaws in passkey implementations or because of security bugs but because of authentication immaturity in general.

For one, most users aren't familiar enough with passkeys yet and don't know how to recognize when a page might be manipulated; for another, implementers may not be aware of how AitM can modify the login view. And the fact remains that offering account recovery options is a must; passkeys are housed on hardware devices so if the device is lost, then there needs to be another way to access the account. Unfortunately, those backups are nearly always vulnerable to AitM.

"If it weren't for the need for account recovery, an AitM-resistant passkey authentication flow could be fairly straightforward, abandoning passwords altogether in favor of passkeys," Stewart wrote in the post. "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."

Indeed, when his team contacted some of the affected vendors, they appreciated the information, he says — but there remains some exasperation with how difficult it is to level up on authentication methods in the consumer realm. For now, it feels as though their hands are tied.

"Everybody's always thinking well, you know, we know this person's going to get locked out at some point, they're going to lose their security key, and so we're going to have to provide all these backup authentication methods, and unfortunately, that plays right back into the hands of the people running the phishing kits," he says. "There's a sense that consumers don't really understand passkeys."

That's not to say there aren't options for better implementations, which Stewart says he wants to proselytize — especially when it comes to magic links for account recovery, which are "probably the most secure method," Stewart says. "Magic links" are sent to an email account and will take users to a new login window to sign in.

"If you click on a link sent to you in email and it opens up a completely new window, then that is a direct connection from you to the real site; you're bypassing the phishing window, it breaks you out of this hijacked session," he says. "And then you can go through the process of securely authenticating with a passkey in case it was redacted in a compromised session."

The one caveat is that this method is only as secure as an email inbox or the SMS network, which are common targets for attackers as well. For that reason, Stewart advocates using extra security layers, such as making sure these are auto-generated one-time links with short timeouts, and that logins are permitted from previously authenticated IP addresses only.

It's also possible to implement "warded links," which are like magic links but also require security questions or backup code entry to use, Stewart says.

On a positive note, some of the providers the team talked to were open to considering such new approaches to thwart AiTM attacks, he adds.

How Enterprises Can Prevent Compromise From Passkey Redaction

Beyond the obvious (using hardware-based keys and requiring fallback passwords to be complex and unique per website), security teams within organizations have a few options for shoring up defenses against forced authentication downgrades, Stewart notes, including using the aforementioned magic and warded links.

For instance, Microsoft's Entra ID (formerly known as Azure AD) and Intune products allow admins to configure conditional access policies that can prevent proxied logins from succeeding, such as enforcing device login from “domain-joined, policy-compliant, managed devices” only.

"Verifying that you're on a domain-joined machine and you can't log into any of these services unless you have the permissions to makes it a lot harder for somebody to just take the credentials and run with them," Stewart explains.

Also, many identity and access management (IAM) solutions for enterprises allow admins to define the login and account recovery flow for the organization, groups, or individual users, so "it may be possible to define a secure, passwordless login flow using passkeys, that isn’t vulnerable to authentication method redaction attacks," Stewart says, citing the open source Keycloak IAM software as one platform with that capability.

In general, security teams should 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.

And finally, "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," Stewart advised in his blog post.

Don't miss the latest Dark Reading Confidential podcast, where we talk to two ransomware negotiators about how they interact with cybercriminals: including how they brokered a deal to restore operations in a hospital NICU where lives were at stake; and how they helped a church, where the attackers themselves "got a little religion." Listen now!