The recent Pass-ta-key attack has sparked confusion and concern among users and security professionals alike, with many questioning the safety of passkeys as a new authentication method. However, this attack, while concerning, is not a novel or unique vulnerability specific to passkeys. The core issue lies in the way passkeys are stored and accessed on Windows machines, which differs significantly from other operating systems. This article delves into the intricacies of passkey storage, the Pass-ta-key attack, and the broader implications for security.
The Pass-ta-key Attack: A Misnomer?
The Pass-ta-key attack, as described by researcher Arie Olshtein, involves malware exploiting vulnerabilities in the Google Password Manager (GPM) app on Windows. The attack leverages the app's ability to synchronize passkeys with a new device, allowing malware to transfer stored passkeys to an infected Windows machine. This raises concerns about the security of passkeys, especially on Windows, as the attack demonstrates a way to extract passkeys from the GPM app.
However, it's crucial to understand that this attack is not a flaw in the passkey system itself but rather an exploitation of specific Windows characteristics. The attack surface is not unique to passkeys but rather a consequence of how Windows manages app permissions and local storage.
Passkey Storage: Local vs. TPM
Passkeys, as defined by the FIDO 2 specifications, are not mandated to be stored in the Trusted Platform Module (TPM) or any dedicated hardware. Most platforms and third-party software store passkeys locally on the device, with the notable exception of Microsoft, which recommends storing passkeys in the Windows TPM for enterprises. This local storage approach enables easy syncing across devices, addressing a critical barrier to widespread adoption.
The shift to local storage was driven by the realization that passkeys needed to be accessible across multiple devices. Requiring TPM storage would have made syncing impossible, hindering the technology's usability. The FIDO Alliance's decision to allow local storage was based on the assumption that app permissions would prevent malware from accessing private keys, a belief that has held true in real-world scenarios.
Windows' Unique Challenge
Windows stands out due to its default app permissions, which grant applications full user privileges. This contrasts with other platforms that encourage restricted permissions for each app. As a result, Windows malware can more easily access data from separate apps, including passkeys stored locally. This is a well-known challenge for Windows, and many third-party developers have responded by storing passkeys in end-to-end encrypted blobs located in the cloud.
The Cloud-Based Solution
Server-stored passkeys, now adopted by GPM for Windows and other third-party apps, offer a solution to the Windows permissions issue. When a Windows user wants to log in using a passkey, the device retrieves the user and/or device key from the TPM and presents it to Google's backend authenticator. The Google server then presents an authentication assertion to the site, ensuring secure access.
This cloud-based approach addresses the security concerns raised by the Pass-ta-key attack, as it relies on the isolation of private keys in the cloud, making it more challenging for malware to access them.
Implications and Future Considerations
The Pass-ta-key attack highlights the importance of understanding the specific security measures in place for each operating system. While the attack demonstrates a vulnerability in Windows, it underscores the need for robust security practices across all platforms. Users should be aware that compromised devices, especially those running Windows, may expose stored data, including passkeys, to potential threats.
In conclusion, the Pass-ta-key attack, while concerning, is not a novel issue but rather an exploitation of Windows' unique permissions model. The attack serves as a reminder of the ongoing challenges in computing security and the importance of staying informed about the specific security measures of the operating systems and applications we use.
