New Pass-ta-key attack reveals all the things we didn't know about passkeys

Last week, a researcher outlined what he said was a “novel attack surface” in passkeys, the new authentication paradigm that offers a more secure alternative to password-based methods. In fact, the attacks demonstrated in the post are neither novel nor unique to passkeys. This distinction is important because the research has generated confusion among end users and security professionals as they assess whether this new mechanism is truly safe to use. The attack is called Pass-ta-key—a blending of the word passkey with the phrase “pass the key” and a nod to a plate of pasta. Arie Olshtein, a researcher at security firm Palo Alto Networks, described in a post last week how Pass-ta-key could obtain all passkeys stored in the Google Password Manager app (GPM) for Windows when it’s running on a machine infected with malware. This came as a surprise to many people because they believed passkeys are stored exclusively in the trusted platform manager (TPM), the locked-down enclave in a hardened silicon chip that’s reserved for storing cryptographic keys and other highly sensitive information on Windows machines. If passkeys are stored in the TPM, then how was Pass-ta-key able to extract the entire set of passkeys stored by the app, they wanted to know. Local passkey storage is OK, with one exception The answer is that, contrary to common belief, the FIDO 2 specifications—managed by the industry group FIDO Alliance—don’t mandate that passkeys be kept in TPMs, or any other sort of dedicated piece of hardware (they go by different names, depending on the platform, including secure enclaves, trusted execution environments, and StrongBoxes). In fact, most platforms and third-party software for managing passkeys do not store passkeys in such dedicated hardware. Virtually the lone holdout is Microsoft, which gives users the option to store passkeys in the Windows TPM. The company mainly recommends this choice to enterprises, not consumers. I still believe passkeys are the overall best available choice, but they’ve not as secure as they could have been, and that’s disappointing. Besides, I keep mine in my password manager. If they get my passkeys from there, I've got WAY bigger problems. that may be minor to you but advantages do exist. The other factor is the device storing the passkey. Resident credentials store information for each service (relaying party or RP in FIDO-speak) on the device/implementation. That allows the RP, via the browser or OS, to ask the device for a list of enrolled FIDO2 accounts. Almost all FIDO2 implementations require that a PIN or other factor be set before credentials can be discovered. For physical passkey holders (such as a Yubikey), the numeric PIN must be entered. For software-based FIDO2 stores, the authentication can be either biometric (fingerprint or face on a phone) or password or session-based. That effectively makes all password-less passkeys 2 factor, since an attacker who obtained just the device (phone, Yubikey, etc) would not have enough to allow the credential to be discovered. Whether that password comes from a password manager or a sticky note doesn't change that fact. Creating distinct passwords for every service and storing them in a manager combats against a remote compromise of one service from impacting other services (password reuse). It does nothing to protect the user from the password itself being compormised. With that buildup I was not expecting you to quote a literal statement of fact. That thread had people saying something incorrect and acting like it was some kind of gotcha which invalidated the concept rather than simply them being confidently wrong. A key concept to understanding security mechanisms is a threat model specifying the problem it is and isn’t intended to solve. Just as a car seatbelt isn’t designed to protect you from fire, passkeys are not designed to stop a complete compromise of your local computer: they’re designed to be easier and safer when authenticating to other computers over a network. They have features which help site operators protect against some threats by requiring a device-bound credential or a presence check but that’s only part of a larger system, just as HTTPS has many protections against a malicious network – the threat it’s designed to counter — but not a malicious client or server: its job is to deliver the bits securely, not to inspect them. Organizations deploying any security tool need to think of that whole system and what compromises they’re willing to accept. A large company can add endpoint management into the mix, for example, but a public site can’t tell users they need to install an MDM so they’re going to have to accept that risk and rely on other things like behavioral analysis and robust recovery mechanisms to help customers avoid the worst impacts. Each of those tradeoffs is reasonable for their respective situations and should be evaluated in the context of the threats they face and practical options for mitigating them. It cannot prevent your device from being compromised. If your device is compromised then so is your password manager. That’s exactly the situation here, meaning all your passwords are equally vulnerable. Based on the user comments I think a few clarifications and points of emphasis might help, because I'm seeing a lot of comments where otherwise technically inclined users are drawing bad conclusions. Most importantly, I think it'll help to emphasize that while the FIDO spec relaxed the secure key store/TPM/SSE requirement to allow for server stored/app synced passkeys, it does not require dropping it, many solutions do not drop it, and users can absolutely avail of those. You do allude to that, but it kind of falls by the wayside. Windows Hello is certainly targeted at enterprise users, but its definitely an option for consumers as well, and is very easy and convenient to use, and does secure keys in the TPM. Passkeys stored in the iOS native solution do use the SSE. Yubikeys can be used. And none of them are susceptible to pas-ta-key. You certainly did mention this, but I think the emphasis is needed, that users who are more security conscious can simply opt to use those type of solutions over a password/passkey/manager/sync/utility like GPM, and they will be safe from pas-ta-key. Instead the comments section has people bemoaning that passkeys are essentially no safer than passwords. And again, while you do allude to OS defense mechanisms which other manager/sync utilities use but GPM does not, it comes off as a footnote. IMO it needs a lot of emphasis, because people are coming away from this article with conclusions like "passkeys suck", "passkeys are insecure", "windows is insecure", "ALL passkey sync solutions are insecure". It's really GPM that should be getting the black eye here -- not any single OS, and definitely not passkeys. PS - I know this is a technically dense subject and you're on a deadline. Appreciate the article.