t is no secret that passwords are highly susceptible to phishing and brute force attacks. This led to the mass adoption of passkeys, a passwordless authentication method leveraging cryptographic key pairs that allows users to log in with biometrics or a hardware key. According to FIDO, over 15 billion accounts have been passkey-enabled, with 69% of users globally enabling passkeys in at least one account. The passkey promise is simple – eliminate passwords, eliminate vulnerabilities. Yet, SquareX researchers Shourya Pratap Singh, Daniel Seetoh and Jonathan Lin disclosed a major passkey vulnerability at DEF CON 33 main stage that puts major banking, shopping and enterprise SaaS app accounts at risk.
Passkeys work by using a pair of cryptographic keys instead of a password. The private key is securely stored on the user’s device, while the public key is stored on the website’s server. When logging in, the user authenticates locally with their biometrics, local hardware key or a PIN to access the private key. The website then verifies this signature with the matching public key to authenticate access. This design strengthens security by tying authentication to a pre-registered device and website, eliminating the risks of stolen, reused, or weak passwords.
Critically, all communication between the server and the user’s device is relayed through the browser. In other words, passkeys work under the assumption that the browser is “honest”. SquareX researchers demonstrated that through relatively trivial scripts and malicious browser extensions, attackers can intercept and forge the passkey registration process, allowing them to access accounts without the real device or biometrics. Even with registered passkeys, attackers can cause the passkey login to fail, forcing users to re-register their passkeys under an attacker controlled environment.
“Passkeys are a highly trusted form of authentication, so when users see a biometric prompt, they take that as a signal for security,” says SquareX researcher Shourya Pratap Singh, “What they don’t know is that attackers can easily fake passkey registrations and authentication by intercepting the passkey workflow in the browser. This puts pretty much every enterprise and consumer application, including critical banking and data storage apps at risk.”
Unfortunately, traditional security tools like EDR and SASE/SSE lack the necessary visibility in the browser to detect passkey exploits. From a user perspective, the attack is identical to a legitimate passkey workflow. In other words, there is zero visual indicator or network signal that can verify the legitimacy of the authentication service and/or request. Thus, the only way to prevent the exploit is to monitor and block any malicious scripts and extensions directly in the browser.
With over 80% of enterprise data now residing in SaaS applications, passkeys are emerging as the dominant authentication method for accessing these platforms. SquareX’s research demonstrated that browsers represent the vulnerable point in passkey security and provide the grounds for multiple attack vectors that malicious actors can leverage to exploit passkeys. Vivek Ramachandran, the Founder of SquareX shares “SquareX has been actively researching new ways attackers exploit employees in the browser. Without a browser security layer, passkeys in isolation can be easily hijacked by attackers to gain unauthorized access to enterprise SaaS apps, where critical data is stored. This underscores the urgent need for Browser Detection and Response, an “EDR in the browser”, which SquareX has been pioneering.”
As passkeys establish themselves as the authentication gold standard, enterprises must ensure robust security measures are in place to protect the environment where users and passkeys primarily operate – the browser.
Legal Disclaimer: The Editor provides this news content "as is," without any warranty of any kind. We disclaim all responsibility and liability for the accuracy, content, images, videos, licenses, completeness, legality, or reliability of the information contained in this article. For any complaints or copyright concerns regarding this article, please contact the author mentioned above.
