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

Skip to content

AI

Biz & IT

Cars

Culture

Gaming

Health

Policy

Science

Security

Space

Tech

Forum

Subscribe

Story text

Size

Small<br>Standard<br>Large

Width

Standard<br>Wide

Links

Standard<br>Orange

* Subscribers only

Learn more

Pin to story

Theme

Search

Sign In

Sign in dialog...

Text<br>settings

Story text

Size

Small<br>Standard<br>Large

Width

Standard<br>Wide

Links

Standard<br>Orange

* Subscribers only

Learn more

Minimize to nav

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 over 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.

Unbeknownst to me until I began research for this article, all platforms other than those running Windows store passkeys locally on the device. The shift to local storage came a few years ago after OS and third-party application developers realized that passkeys had no chance of gaining widespread usage unless they could easily be synced to all of a user’s devices. Requiring TPM storage made syncing impossible. The only way to load them into the TPM of a new device would be to re-create each one individually.

Ultimately, architects of the FIDO specifications decided that it was generally safe to store passkeys on the devices. The thinking was that app permissions are so granular that malware lurking on the device would have no ability to access the private keys that form the lynchpin of passkey security. Malware installed on a device running macOS, iOS, and Android, for instance, has no ability to defeat this isolation unless the OS itself is compromised through some sort of exotic zero-day exploit. So far, these assumptions have been proven correct in real-world practice.

The lone exception is Windows. Unlike all the other platforms, Windows apps generally run with all the privileges of the user, whereas other platforms encourage the restriction of the privileges of each application by default. While Windows provides some sandboxing protections designed to isolate apps, it doesn’t prevent unsandboxed apps, such as malware, from accessing the data of a sandboxed app. That is, the sandbox only protects in one direction. Sandboxing technologies on other platforms are much more protective.

That means Windows malware has decidedly fewer problems accessing data used by a separate app. Passkey architects have been keenly aware of this difference, which is largely necessary for Windows backward-compatibility reasons. With no confidence that passkeys stored on a Windows device won’t be harvested in the event of a malware infection, many third-party developers opted for a new design—storing the passkeys in end-to-end encrypted blobs located in the cloud. Server-stored passkeys are now the design used not just by GPM for Windows, but 1Password, Dashlane, and other third-party apps for the Microsoft OS as well.

At a simplified level, here’s how it works: When a Windows GPM user wants to use a passkey to log in to a site, the device retrieves a user and/or device key from the TPM and presents it to Google’s backend authenticator. Presentation of the key,...