Your passkeys could be vulnerable to attack, and everyone – including you – must act

Follow ZDNET: Add us as a preferred source on Google.

ZDNET’s key takeaways

• A researcher developed an exploit that hijacks passkey authentication.
• The exploit depends on a non-trivial combination of pre-existing conditions.
• Neither the passkeys nor the protocol was proven to be vulnerable.

At this year’s DEF CON conference in Las Vegas, white hat security researcher Marek Tóth demonstrated how threat actors could use a clickjack attack to surreptitiously trigger and hijack a passkey-based authentication ceremony. 

In the big picture, this is a story about how password managers could be tricked into divulging login information — either traditional credentials such as user IDs and passwords or credential-like artifacts associated with passkeys — to threat actors. 

Also: 10 passkey survival tips: Prepare for your passwordless future now

Are password managers to blame? Tóth — the researcher who discovered the exploit — suggests that they are, but the answer is more complicated.

Fully locking down any automated process is invariably the result of security in layers. Across the grand majority of use cases where digital security matters, there’s almost never a single silver bullet that wards off hackers. Depending on the layers of technology that combine to complete a workflow (for example, logging into a website), responsibility for the security of that process is shared by the parties that control each of those layers. 

Yes, the password managers are one layer in stopping the exploit. But website operators and end-users — the parties in control of the other layers — must trade too much security for convenience in order for the exploit to work. Pointing fingers is useless. All parties at every layer must take action. 

The big ideas behind passkeys

Every summer, the cybersecurity industry gathers in Las Vegas for the back-to-back Black Hat and DEF CON conferences, where security researchers take turns presenting their “big reveals.” During the year leading up to the event, these researchers work to discover new, unreported vulnerabilities. The bigger the vulnerability and the more users affected, the greater the attention (and possibly the financial reward) that awaits a researcher.

 Also: How passkeys work: The complete guide to your inevitable passwordless future

This year, several researchers announced a handful of issues that challenged the supposed superiority of passkeys as a login credential. 

Here on ZDNET, I’ve been writing a lot about passkeys and why, from the security and technical perspective, they’re immensely better than user IDs and passwords (even when additional factors of authentication are involved).

The three big ideas behind passkeys are:

1. They cannot be guessed in the way passwords often can (and are).
2. The same passkey cannot be reused across different websites and apps (the way passwords can).
3. You cannot be tricked into divulging your passkeys to malicious actors (the way passwords can).

Unfortunately, despite their superiority, the passkey user experience varies so wildly from one website and app (collectively, “relying parties”) to the next that passkeys risk being globally rejected by users. Despite these barriers to adoption, and in the name of doing the most to protect yourself (often from yourself), my recommendation continues to be: Take advantage of passkeys whenever possible.

Also: I’m ditching passwords for passkeys for one reason – and it’s not what you think

In the interest of delivering sound advice to ZDNET’s readers, I always double-check the veracity of any headlines that challenge the viability and superior security of passkeys. Various reports emerged from this year’s Black Hat and DEF CON, citing potential trouble in passkey paradise. The one that got the most attention came from Tóth, who — under a combination of very specific technical preconditions — has discovered a way to hijack passkey-based authentications while those authentications are in progress. 

My research involved lengthy communications with Tóth, officials from the FIDO Alliance (the organization responsible for the development and promotion of the passkey standard), a developer of a turnkey plug-in that enables websites for passkey-based authentication, and vendors of various password managers. Why the password managers? From the end-user’s perspective, it’s impossible to engage in passkey-based authentication — technically known as an “authentication ceremony” — without the assistance of a password manager. They play a key role in Tóth’s findings. 

As for the FIDO2 Credential passkey specification itself, Tóth told me, “The protocol itself is probably secure. I haven’t tested it extensively, as it wasn’t the focus of my research.” In other words, he is not suggesting that passkeys themselves are insecure. In fact, Tóth’s research covers user IDs and passwords, too, and his findings essentially prove that those traditional credentials are far more exploitable than properly configured passkeys ever will be. 

However, through a combination of sloppy website management and user indifference when it comes to securely configuring their password managers, there exists a previously undisclosed opportunity for malicious actors to hijack a passkey-based authentication ceremony while it’s in progress. This is true even though passkeys themselves cannot be stolen. 

Also: The best password managers: Expert tested

Instead of pointing his finger at the FIDO2 specification or careless website operators, Tóth primarily blames the password managers, who, in his opinion, could have done more to protect the user from his exploit.

 “No, it’s not only the website operator’s fault,” Tóth wrote to me via email. “But also the password manager vendors, since the vulnerability is in their software.” In a tweet where Tóth summarizes some of his findings, he calls out 12  password managers (including all the popular ones) by name as being vulnerable to one extent or another.

Whether or not the various password managers are indeed vulnerable depends on your definition of “vulnerability.” None of the password management vendors that I contacted agreed with the assertion that their password manager had a vulnerability. 

However, given the aggressive browser permissions that users must grant to their password managers at the time of installation (the same permissions that make it possible for a password manager to prevent rogue usage of unsanctioned SaaS apps), password managers are in a unique position to detect and prevent this and other threats before damage is done. 

Not surprisingly, some of the password managers are releasing new versions to address Tóth’s exploit. 

The heart of the attack

Although the exploit happens in the blink of an eye, it involves a complicated set of interactions and preconditions that, taken together, present a series of non-trivial obstacles to the attacker’s chances of success. At its heart, Toth’s exploit never steals a user’s passkey (one of the core tenets of passkeys is that they can’t be stolen). But it essentially steals the next best thing. 

At the moment that a user is tricked into inadvertently authenticating to a website with a passkey, the exploit intercepts a payload of information that was manufactured by the user’s password manager with the help of his or her passkey to that site. As described in part 5 of my series on How Passkeys Actually Work, this payload is called the PublicKeyCredential, and it’s like a one-time single-use golden ticket that contains everything necessary for the user to log into their account on the legitimate website. Once the attacker gains possession of this golden ticket, it can be used to log the attacker’s system into the victim’s account as though the attacker’s system is the victim’s system.

Also: What really happens during your ‘passwordless’ passkey login?

And that’s exactly what this exploit does. 

After loading malware into the victim’s browser, the exploit — a malicious cross-site script (XSS) — intercepts that golden ticket and, instead of presenting it for entry into the legitimate site (as the user’s browser typically does at the request of the password manager), it sends it to the attacker’s website. Then, with that golden ticket in hand, the attacker submits that same ticket from their own system to the legitimate website, effectively logging the attacker’s system into the user’s account on the legitimate website. 

But, as mentioned earlier, Tóth’s discovery relies on the pre-existence of several conditions involving the website in question, the user’s choice of password manager, how they have that password manager configured, and the website operator’s choice of technology for adding the ability to authenticate with a passkey. Whether you’re an end-user, the operator of a website, or the vendor of a password manager, it’s important to understand these conditions because, once you do, you’ll also understand the defense. You can also judge for yourself who among the involved parties is most responsible for the vulnerability. 

While Tóth points his finger at the password managers, I believe that the website operator would be mostly to blame if an actual threat actor used this exploit in the wild. Setting aside for a moment the challenge of getting the victim to encounter the malware (a malicious cross-site JavaScript that runs in the victim’s browser), there are two settings that foil the attack that every professional website operator should know about. 

Also: 3 reasons VPN use is set to explode worldwide – and that might apply to you

There comes a moment during the passkey authentication ceremony — once the user has indicated the desire to log in with a passkey — when the website responds to the user with a challenge as a part of a larger payload called the PublicKeyCredentialRequestOptions. Like every response from a web server, that response also includes several parameters known as HTTP headers, one of which can be used to establish a specific communication session with the client system using a uniquely coded cookie, and then to configure that cookie as an HttpOnly cookie. 

A simplified version of that header parameter — known as the set-cookie parameter — might look something like this (as a part of a larger transmission from the web server to the user’s browser):

Set-Cookie: session_id=123456789abcdefg; HttpOnly

When a web server is configured to include a header like this during a user’s attempt to authenticate with a passkey, it permanently glues the challenge (and the rest of the conversation between the user’s browser and web server) to the specified session ID. Once a challenge is bound to a specific session ID, the server will only honor a golden ticket that’s packaged with that same ID. For Tóth’s exploit to work, the attacker’s system must not only take possession of the intercepted golden ticket, but it must also know the exact session ID to use when presenting that ticket to the legitimate web server. 

This is where the HttpOnly parameter comes into play. When the set-cookie header includes this parameter (as shown above), it’s like a magical invisibility cloak. The session ID becomes invisible to any JavaScript — legitimate or malicious — that might be running in the user’s browser. As a result, if that JavaScript happens to be malicious, it can’t do what Tóth’s exploit does; it can’t discover the session ID, nor can it include it with the intercepted golden ticket that it forwards to the attacker’s system. So, even if the malicious JavaScript forwards the intercepted golden ticket to the attacker’s system, it would be useless to the attacker without the missing session ID. 

Also: How I easily set up passkeys through my password manager – and why you should too

For eons, this “session-binding” of an authentication conversation (passkey-related or not) between a website and the end-user’s browser has been considered the primary line of defense against such an attack. A website operator’s failure to lock its authentication processes down with this simple, well-known best practice would be viewed by most cybersecurity professionals as highly negligent. 

Plenty of blame to go around

But in my interviews with Tóth, he also blames two other groups: the solution providers that sell the plug-ins used by relying parties to add passkey support to their websites, and the FIDO Alliance, the organization responsible for the development, promotion, and adoption of passkeys. 

In his research, Tóth noted that, of the seven plug-in solutions he tested, four “did not implement ‘session-bound challenge,’ [thus] making this attack exploitable.” In other words, if a website operator installed one of those four libraries (from Hanko, SK Telecom, NokNok, or Authsignal) and left them in their default state, it would be the equivalent of disregarding the best practice. 

Also: Microsoft Authenticator won’t manage your passwords anymore – or most passkeys

Tóth was also incredulous that the FIDO Alliance included those four solutions in its online showcase of FIDO-certified solutions. In Tóth’s opinion, flaunting the widely known best practice and defaulting to non-session-bound challenges should disqualify a plug-in from FIDO’s certification. The FIDO Alliance disagrees. 

FIDO Alliance CTO Nishant Kaushik told me:

“Regarding the four companies you pointed out as not using session binding, it’s worth noting that the researcher tested demo sites that these companies leverage to showcase the user experience that their products provide. Demo sites would not typically be hardened in the same manner as an actual implementation.” 

Kaushik went on to talk about the criticality of session binding, saying that the FIDO Alliance-operated passkeycentral.org includes a post demonstrating that “the FIDO Alliance [has been] clear that session-binding is ‘essential’ to prevent session hijacking.” However, the article refers to cryptographic session-binding techniques such as Device Bound Session Credentials (DBSC) and Demonstrating Proof of Possession (DPoP), and fails to suggest the far simpler and widely publicized best practice of session-binding with the set cookie header.  

Additionally, whereas the FIDO Alliance defended its certifications, essentially claiming that no one would realistically deploy the plug-ins in the manner that Tóth did, the CEO of one of those plug-ins struck a far more genuine, conciliatory and culpable tone in a way that called the accuracy of Kaushik’s response into question.

“We’re aware of the issue and our team is actively working on a fix,” said Hanko.io CEO Felix Magedanz. “The passkey implementation is one of the earliest components of Hanko. While we have since added functionality such as sessions and user management, a gap remained in how WebAuthn flows were bound to user sessions. We’re treating this with the highest priority and will release an updated version of Hanko very soon.”

While fixes come from Hanko.io (and maybe the others), it’s abundantly clear that the onus is on relying parties to implement session binding responsibly to better protect their end-users.

Layers upon layers

But let’s assume, as Tóth does, that the website operator has catastrophically ignored one of the most important and well-known techniques for securing an authentication workflow. Tóth’s exploit still involves some other non-trivial pre-conditions. 

The first of these involves the installation of a malicious script into your web browser. Pointing to a 2019 HackerOne post that documented the existence of a malicious XSS on PayPal, Tóth says that end-users should assume that even the most reputable and supposedly well-defended websites can be the source of such malicious scripts. In my conversations with him, he noted that sites that include a significant amount of user-generated content are a favorite target of threat actors because they can add scripts to a post or a review and, if the site lacks the adequate protections to refuse such entries (another act of negligence on behalf of the site operator), all an innocent user must do is visit that post or review in order to execute the malicious script. 

Assuming a user stumbles across such a site and loads the malicious script into his or her browser, the script must surreptitiously trick the user into inadvertently launching an authentication ceremony with a type of attack known as a clickjack attack.

Also: Syncable vs. non-syncable passkeys: Are roaming authenticators the best of both worlds?

As the phrase suggests, a clickjack attack happens when a threat actor tricks you into clicking on a clickable element (e.g., a button or a link) that might not be visible to you. In Tóth’s exploit, the malicious JavaScript paints the browser window with a seemingly innocent dialog like a pop-up ad or cookie consent form — the sort of thing we see all the time and just want to clear off our screen. However, when we click on that element to get rid of it, what we don’t realize is that we’re actually clicking on something else that was hidden behind it. Insidious, right?

At that moment, your mouse click has essentially been hijacked. But what have you actually clicked on?

In Tóth’s proof-of-concept, his malicious script involves a hidden login form, which in turn triggers your password manager into action (as password managers typically do when they detect the presence of a login form). Then, the click he hijacks is the one that instructs the password manager to prepare a golden ticket for transmission back to the legitimate website. Theoretically, since the login form was concealed from view, you don’t even realize that you’ve just completed a passkey authentication ceremony. Once the password manager readies that ticket for transmission, the malicious script intercepts it and, instead of sending it (with an HTTP POST command) to the legitimate server, it HTTP POSTs it to the attacker’s server as described earlier. 

But, as was just suggested, the attack isn’t possible without the involvement of the user’s password manager. So, what — if anything — can be done by the password manager to mitigate the attack?

The pros and cons of nagging

When proponents describe passkeys as being more secure than traditional credentials, they often talk about how the passkey process is as simple as logging into your phone with a biometric (fingerprint, Face ID, etc.) or PIN code. For example, on one of its support pages, Microsoft states, “Passkeys are a replacement for your password. With passkeys, you can sign into your Microsoft personal account or your work/school account using your face, fingerprint, or PIN.” Even the FIDO Alliance-operated passkeycentral.org’s introduction to passkeys states, “A passkey is a FIDO authentication credential based on FIDO standards, that allows a user to sign in to apps and websites with the same steps that they use to unlock their device (biometrics, PIN, or pattern)” — as though that’s always the case.

Other passkey proponents include strikingly similar language on their websites that makes it sound as though every time you try to authenticate with a passkey, you’ll have to furnish a biometric or PIN to complete the process (similar to that of logging into a mobile app that prompts you for a fingerprint). However, this is mainly the case when your password manager is also configured to require a biometric or PIN for every authentication attempt. Since some users don’t want to be nagged with this additional layer of security each time they login to a website, most password managers give users the option of relaxing the nagging. In other words, you can set it to nag you every time, every now and then, or never. 

Also: What if your passkey device is stolen? How to manage risk in our passwordless future

Recall that Tóth’s exploit depends on the user getting tricked into inadvertently authenticating with a website. In other words, it hides all the visual cues that an authentication is in progress so as not to alert the user to the possibility of suspicious activity. If your password manager is configured the way mine is — to require a PIN or a biometric to allow any authentication ceremony to continue — you would instantly realize that something is amiss. Suppose, for example, the clickjack attack requires you to click the “Accept” button on a cookie consent form. If your password manager suddenly springs to life, asking for your fingerprint or a PIN after clicking that button, it should be a glaring red flag not to continue. A cookie consent form doesn’t need your fingerprint. 

By setting your password manager to more aggressively prompt you for your fingerprint, PIN, or password, you’re essentially adding a pause button to the authentication process. It gives you a chance to confirm that the password manager is doing something that you actually intended it to do. Choosing a more relaxed setting for this preference is the equivalent of relinquishing an important user-controlled layer of security to threat actors. 

Tóth agreed with this assessment but noted that many users might be unaware of how, during installation, some password managers default to a more permissive setting. It’s a fair point. But it’s also a reminder of how, in the constant pursuit of great personal opsec (operational security) practices, users must progressively take security precautions after educating themselves on the security options that are available to them.

The nuclear option

However, even when users have neglected to batten down their hatches, website operators have a special nuclear option at their disposal. In addition to making all authentication ceremonies session-bound and applying the necessary countermeasures to prevent threat actors from installing malicious JavaScript into users’ browsers, relying parties also have the power to override users’ preferences for when password managers prompt them for their biometrics, PINs, or passwords. 

Also: The best Bluetooth trackers: Expert tested

When the relying party sends the aforementioned challenge to the password manager as a part of the PublicKeyCredentialRequestOptions payload, it can also include a special flag called the userVerification parameter. This parameter allows for three possible settings: Discouraged, Preferred, and Required. If the relying party sets the userVerification flag to “Required”, the password manager is obligated to prompt the user for a biometric, PIN, or password regardless of how the user has configured that password manager. In other words, the website operator has a way of forcing the user to experience the prompt in a way that should alert them to the website’s unexpected behavior.

There is one possibility that would render the nuclear option moot: What if the password manager simply doesn’t honor the “Required” option when specified by the relying party? But, of the password manager providers I randomly sampled (1Password, BitWarden, LastPass, and NordPass), all indicated that they fully honor the “Required” setting when specified as a part of the PublicKeyCredentialRequestOptions from the relying party. 

If you see something, say something 

OK. As an end-user, you have little to no control over the sites you visit. You’re acting on blind faith that they’re doing all they can do to stop an attack of this nature — but you can never be sure. At the same time, you’re logging in and out of so many sites that setting your password manager for its most aggressive form of re-authorization is driving you crazy, and you’re left wondering if there’s an alternative safety net. 

To answer that question, we need to go back to the password managers. As it turns out, in order for your password manager to do what it does, you must grant it the sort of permissions that you should pretty much never give to any other web browser extension. Your password manager can not only read all of the content of every web page you visit, but it can modify it as well. And, because of those permissions, your password manager can also spot the telltale signs of a clickjack attack in progress. 

Also: The best secure browsers for privacy: Expert tested

For example, in order to do what it normally does (e.g., autofill user IDs and passwords), your password manager must detect the presence of a login form. However, because the password manager can parse through every bit of HTML that makes up a web page, it can also take action after detecting if a login form is concealed from your view or if that login form is overlaid by other clickable objects (the true mark of a clickjack attack). 

Although I didn’t contact all password manager vendors, I spot-checked with a handful. Not surprisingly, updated versions of their software are in the works or have already been released. 

“Bitwarden has implemented mitigations for this class of attack in the most recent releases out last week,” according to BitWarden director of communications Mike Stolyar. “Recent updates introduced safeguards that disable inline autofill when site styling suggests potential manipulation, such as hidden overlays or opacity changes.”

Via email, 1Password CISO Jacob DePriest told me that “on Aug. 20, 2025, we released version 8.11.7, which adds the option for users to be notified and approve or deny autofill actions before they occur. This extends the existing confirmation alert for payment information, an alert that cannot be hidden or overlaid by clickjacking, giving users greater visibility and control before anything is filled.”

“NordPass icons are now rendered with the highest z-index, preventing anything from being overlaid on top of them,” said NordPass head of business product Karolis Arbaciauskas. “It is also now impossible to change the dialog’s style attribute, which previously allowed the dialog to be made invisible.”

LastPass has also strengthened its defenses against potential clickjack attacks. The latest update “is to detect zero-opacity types of elements and not [autofill],” said LastPass director of product management Greg Armanini. When I asked if LastPass gives the user a warning about any potential risky behavior that it might have observed on the current web page, Armanini responded that “in the first release, it will just appear as though nothing happens.” But, [if we decide to take the fix a step further], it would probably be similar to what we do already for your credit cards, which is a prompt to say ‘Before you do this, be sure you trust this site.'”

Also: The best password manager for families: Expert tested and reviewed

Meanwhile, Tóth is monitoring the various password managers to see how their updates — some already applied, others still forthcoming — are faring against his test methodology. He was also quick to point out how the updates alone won’t help unless users install those updates. As long as users stay on old versions of their password managers, they could fall prey to a zero-opacity clickjack attack. 

Finally, despite the potential for a threat actor to hijack a passkey authentication ceremony once the non-trivial preconditions are met, Tóth’s exploit offers additional evidence that passkeys are more secure than traditional credentials. Session-binding renders the one-time passkey-generated golden ticket unusable from the attacker’s system. However, it does nothing to stop the threat actor’s exfiltration of the user’s ID and password when Tóth’s clickjack attack encounters an attempt to authenticate with those traditional credentials versus the more time-sensitive and secure passkeys.