New 'Pass-ta-key' Attack Highlights Passkey Security Nuances

A security researcher recently detailed a method dubbed "Pass-ta-key," which purports to expose a novel attack surface within the passkey authentication system. While the attack, which targets passkeys stored in Google Password Manager (GPM) on Windows machines infected with malware, has generated significant discussion, its novelty and uniqueness to passkeys are subjects of debate among security experts. The findings raise questions about the security of passkeys, a system designed to replace traditional passwords.

Arie Olshtein, a researcher at Palo Alto Networks, described in a blog post how the Pass-ta-key attack could potentially extract all passkeys stored within the GPM application for Windows if the machine is compromised by malware. This revelation surprised many, as a common assumption is that passkeys are exclusively stored within a device's Trusted Platform Module (TPM), a secure hardware enclave for sensitive cryptographic data on Windows systems. The concern is that if passkeys are indeed stored in the TPM, how could an attack retrieve them?

Understanding Passkey Storage and Security

The FIDO 2 specifications, managed by the FIDO Alliance, do not mandate that passkeys be stored in TPMs or similar dedicated hardware. These secure environments can also be referred to as secure enclaves, trusted execution environments, or StrongBoxes, depending on the platform. In practice, most platforms and third-party passkey management software do not utilize such dedicated hardware for storage. Microsoft's Windows offers an option to store passkeys in its TPM, a feature primarily recommended for enterprise users rather than general consumers.

A significant shift occurred several years ago when operating system and application developers realized that widespread adoption of passkeys would be impossible without seamless syncing across devices. Mandating TPM storage would have hindered this syncing capability, as loading passkeys onto a new device would necessitate re-creation of each one individually. Consequently, the architects of the FIDO specifications concluded that storing passkeys locally on a device was generally acceptable. The prevailing logic was that granular app permissions would prevent malware from accessing the private keys that are fundamental to passkey security. For example, malware on macOS, iOS, and Android typically cannot bypass the isolation mechanisms protecting these keys unless the operating system itself is compromised by an advanced zero-day exploit.

Windows presents a different scenario. Unlike other platforms that encourage restricting application privileges by default, Windows applications generally run with the user's full privileges. While Windows employs some sandboxing techniques to isolate applications, these measures do not prevent unsandboxed malware from accessing data belonging to sandboxed applications. This one-way protection means that malware on Windows faces fewer obstacles in accessing data from other applications. Passkey architects have long been aware of this distinction, which is partly due to Windows' need for backward compatibility.

Given the uncertainty surrounding the security of passkeys stored on a compromised Windows device, many third-party developers have opted to store passkeys in cloud-based, end-to-end encrypted blobs. This approach is used by GPM for Windows and other popular third-party password managers like 1Password and Dashlane when operating on Microsoft's OS. The process typically involves retrieving a user or device key from the TPM, which is then presented to a backend authenticator. This, combined with the user's active Google account session, prompts the server to generate an authentication assertion for the target website, signed by the private key stored securely in an encrypted format on the server.

In contrast, the same third-party applications on other platforms usually store passkeys locally on the device. When a user initiates a login, the local device, rather than a cloud service, presents the authentication assertion, signed by the private key residing in an encrypted format on that local device.

The Pass-ta-key attack leverages malware's access to a compromised Windows machine's Google account and, in some instances, the user or device key from the TPM, to obtain the stored passkeys. One of the most potent variants of the attack tricks the infected Windows machine into impersonating an iPhone. This activates a synchronization feature within GPM, enabling the transfer of all stored passkeys to the compromised Windows device.

While Olshtein described Pass-ta-key as a novel attack, security analysts note that the underlying risk is not entirely new. Similar risks exist if a compromised Windows machine gains authenticated access to other sensitive applications. The potential for an attacker to activate credential management features or download all stored passwords is a long-standing concern associated with password managers. Some analyses suggest GPM might lack certain protective measures found in competitors like 1Password, such as APIs to prevent other processes from accessing its memory. However, the general consensus in cybersecurity is that a compromised device logged into a sensitive account signifies a complete loss of security.

The fundamental purpose of passkeys is to eliminate shared secrets susceptible to phishing or server breaches. They are not designed to defend against direct physical attacks on the devices storing them. The Pass-ta-key research, though perhaps not groundbreaking in its core mechanics, serves as a valuable reminder: once a device, especially a Windows machine, is compromised while logged into an account, all data residing on it becomes vulnerable.