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. 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. 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. This year, several researchers announced a handful of issues that challenged the supposed superiority of passkeys as a login credential. 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. 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. 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. 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. Read this complete 2 part article on Our Forum.