PasskeyScanner: A Kroll BurpSuite Extension for Passkeys
Despite being a globally accepted security measure, passwords have associated issues that have led to countless breaches and compromised systems over many years of not-so-secure authentication technology. Yet passwords remain the dominant form of authentication because more secure options have not been accessible to all users. Passwords have evolved into the security risk they are today because, as the security requirements for passwords have increased, usability has decreased. Less technically capable users are more vulnerable because good password hygiene requires technical capacity and effort to maintain. Users are not to blame; this is a technology problem that can only be solved by technology. The evolution of password usage follows a repeating cycle that is failing both users and technology administrators.
While password practices have become more complex over time to defend against attackers, they demand too much of users and increase potential security risks.
Figure 1: The password usage failure cycle.
User Challenges | Attacker Wins | Defender Effort |
|---|---|---|
Users have to remember passwords, so they choose something easy to remember, like their favorite sports team or the word “password.” | Easy-to-remember passwords are also easy to guess via dictionary wordlists. | Password complexity became necessary, requiring systems to ensure that passwords contain special characters, numbers and sufficient length. Password rotation is introduced to reduce the longevity of compromised passwords. |
Complexity requirements make passwords even harder to remember, so users memorize a few strong passwords and reuse them. | Reused passwords are common, and database leaks are also common due to weak passwords. Credential stuffing with lists of previously breached credentials is effective for attackers. | Passwords must be checked against breach lists. Rate limiting, account lockout and risk profiling must be implemented. |
Users must use password managers and ensure any reused passwords are updated. | Phishing and social engineering become more popular with attackers since they continue to be effective. | Multi-factor authentication is implemented. |
What Are Passkeys?
Passkeys use public key cryptography to authenticate users. This allows the secret key to be stored on a user’s mobile or laptop device without being exposed to another party. Access to the secret key involves verifying a user, typically by a biometric, such as fingerprint or faceprint. After verification, the device uses a cryptographic protocol to authenticate the user.
Passkeys have a number of specific properties that are critical to achieving this standard of security:
- They are built on established standards scrutinized by security professionals and attackers, providing full security assurance.
- They have been adopted by the major platform vendors (Apple, Google and Microsoft), which provide backup and cross-device synchronization. If a user loses their device, they don’t lose access to all their accounts. Adoption by these vendors also means that most modern consumer devices will have access to Passkeys.
- The use of public key cryptography means that services hold a user’s public key rather than a shared secret, such as a password. If a service is breached, the user is not at risk of having their credentials stolen and leaked.
- Passkeys bind public keys to website domains, so only the site that issued the credential can use it to authenticate. This makes Passkeys extremely resistant to phishing.
- Users are presented with a simple dialog that enables them to choose their account and then asks them for a (biometric) verification.
Figure 2: The Passkey dialog allows the user to choose an account and complete Face ID verification
Core Passkey Technology
Passkey technology has three facets that are all related and are often confused with each other:
- Web Authentication (WebAuthN) is the communication specification (or API) used to perform the authentication ceremony. It defines the messages passed between web servers (also known as Relaying Parties), web scripts running in the browser and calls to the browser APIs. The browser APIs expose two functions that are WebAuthN:
- Authenticate (navigator.credentials.get()) — used to authenticate the user.
- Create Passkey (navigator.credentials.create()) — used to create a new Passkey credential for a user.
- FIDO2 is the full set of authentication technologies. It includes WebAuthN and continues deeper into the technology stack to include how the browser or operating system selects and communicates with any available authenticators
- Passkeys are the implementation of FIDO2 by the major platform vendors, agreed upon by the FIDO alliance. The agreement to implement FIDO2 on these platforms allows for strong cross-platform authentication, which is available (or will soon be available) for most users. Passkeys also includes account-based recovery and credential syncing across devices, eliminating significant usability challenges that limited prior technologies.
“Passkeys” is preferred over “FIDO2” when the terms can be interchanged because the adoption by the major vendors is a key to Passkey’s success, and the term is more user-friendly.
Introducing Kroll PasskeyScanner
Passkeys have been adopted by the major platform vendors, incentivizing application developers to build Passkeys into their applications. Vendors such as Adobe, Amazon, Best Buy, GitHub, Google, PayPal, Shopify and TikTok have already deployed Passkey authentication.
Kroll’s Offensive Security team provides penetration testing and other offensive security assessments to clients globally. To ensure that we are equipped to properly assess Passkeys, we have developed proprietary methodology and tooling.
As part of this, we created a BurpSuite extension called PasskeyScanner that helps our security consultants evaluate implementations of Passkeys. This plugin is freely available in the Portswigger Bapp Store to contribute some of our efforts to the community. We also presented a talk at a HackFest event where we released this plugin and gave a more detailed overview of the Passkeys attack surface.
How Kroll Passkey Scanner Works
Kroll PasskeyScanner performs passive scans of network traffic to detect either of the WebAuthN transactions: create passkey or authenticate. It parses the requests and evaluates fields for secure configuration, best practice and correct implementation. The checks it currently performs are:
Verifying the Public Key Algorithms and Elliptic Curves
When a keypair is created for credentials, the Relaying Party and Authenticator must agree on an acceptable algorithm. This process starts with the Relaying Party sending a list of acceptable algorithms in order of preference. The algorithms are encoded using the IANA CBOR Object Signing and Encryption (COSE) algorithm registry. PasskeyScanner will scan this list and report unacceptable algorithms. The registry includes a “recommended” field, so we use this guidance as a starting point to determine which algorithms are acceptable. However, this approach is not perfect for two cases:
- Many algorithms are symmetric encryption algorithms, which are inappropriate for Passkeys. Symmetric algorithms are reported as a finding if they’re found in the list of supported algorithms.
- RSA PKCS v1.5 is a signature scheme based on RSA public keys that is still commonly used. The PKCS v1.5 structure has led to padding oracle attacks in several implementations of this format. RFC 3447 (2003) PKCS #1 RSA Cryptography Specification (#section-8) recommends that PKCS v1.5 is not adopted for new applications.
If the authenticator decides to generate an elliptic curve keypair for a credential, the public key is returned to the Relaying Party. The public key is CBOR encoded within the “attestationObject.” This plugin will decode the “attestationObject” and verify that the encoded algorithm identifier matches with the curve specified in the public key (e.g., the ES256 algorithm has a public key on curve SECP256R1). If an algorithm and public key curve mismatch is found, a finding will be reported.
User Verification
Passkeys provide a feature to enforce user verification during authentication. For users utilizing a mobile device, this is typically a biometric verification. If user verification is not “required,” we report a finding since this feature provides additional security if an authenticator is lost or stolen. Windows will often perform this verification by requiring the user to enter the login credentials, which may become a usability constraint on the user. The user verification being set to “preferred” will allow the passkey implementation to determine if user verification is required, which may be an appropriate balance of usability and risk for some applications.
Strong Authentication Challenge
To demonstrate proof of the secret key, WebAuthN requires the authenticator to cryptographically sign an authentication challenge. If the challenge is predictable or an attacker can bias the challenge string, the cryptographic strength of the authentication ceremony is weakened. WebAuthN requires that the challenge is at least 16 bytes (128 bits), and a length of 32 bytes (256 bits) is commonly implemented. If a challenge is less than 16 bytes, a finding is reported.
‘AllowCredentials’ Information Disclosure
The “AllowCredentials” parameter is an optional list that can be provided for the authentication operation. It specifies a list of acceptable credential IDs to the relaying party. It is intended to support “non-resident” or “server-side” credentials, maintaining retrospective compatibility with older WebAuthN authenticators. The “AllowCredentials” array is a list of credential objects that contain an ID and type field. With Passkeys, the credential type will always be “public-key,” but a system may also allow other credential types. If the relaying party provides a list of allowed credentials that includes a weaker form of authentication, such as “password,” this gives a threat actor useful information about which accounts to target in a password attack. If any credential type other than “public-key” is provided, a finding is reported.
User Handle Personally Identifiable Information
The user handle is the “ID” field of a user object that may be stored with the credential by the authenticator. To protect user privacy, a user identifier should not be personally identifiable information. An authenticator may reveal a user handle without verification of an authentication operation from the user, which could allow a script to perform user enumeration. This also prevents user enumeration attacks against a relaying party in which a user attempts to enumerate site users by seeking to authenticate many user accounts.
The Next Step in Authentication Tech
Passkeys are set to be a huge leap forward in authentication technology by providing a usable, secure and widely available option. Our team of security consultants is proud to contribute to this effort by working with Passkey deployments and ensuring our clients have implemented the most secure version of this technology.
Download Kroll PasskeyScanner extension now.
Stay Ahead with Kroll
Cyber and Data Resilience
Kroll merges elite security and data risk expertise with frontline intelligence from thousands of incident response, regulatory compliance, financial crime and due diligence engagements to make our clients more cyber resilient.
Cyber Risk Assessments
Kroll's cyber risk assessments deliver actionable recommendations to improve security, using industry best practices & the best technology available.
Incident Response & Recovery
Kroll’s elite security leaders deliver rapid responses for over 3,000 incidents per year and have the resources and expertise to support the entire incident lifecycle, including litigation demands. Gain peace of mind in a crisis.
Cloud Security Services
Kroll’s multi-layered approach to cloud security consulting services merges our industry-leading team of AWS and Azure-certified architects, cloud security experts and unrivalled incident expertise.