Cybersecurity
Passkeys: A Modern Approach to Authentication
As cyber threats escalate traditional password-based authentication methods are proving inadequate, leaving users and organizations vulnerable to security breaches. While several password-less methods have emerged, including biometrics and one-time passcodes, they often face limitations such as vulnerability to phishing, device compromise, and reliance on third-party services. By adopting passkeys early, organizations can not only strengthen their defenses against password related security threats but also simplify their operations, reduce costs, and foster greater trust in their digital interactions.
This white paper advocates for the adoption of passkeys, a revolutionary password-less authentication standard developed by the FIDO Alliance, as a robust and forward-thinking solution that enhances both security and user experience. We will explore how passkey-implementation overcomes the challenges posed by other password-less approaches and presents a more secure, streamlined solution which offers valuable insights for organizations looking to transition to a more secure and efficient authentication model, positioning themselves for long-term success in a password-less future.
Introduction
Imagine a world where remembering passwords is a thing of the past - where security is seamless, user-friendly, and resistant to today's most sophisticated cyber threats. Welcome to the era of passkeys: the future of authentication.
In today's digital landscape, traditional password-based authentication methods are no longer sufficient to protect against the growing threats of cyberattacks. Users face password fatigue, leading to weak and reused passwords that are highly susceptible to hacking, phishing, and credential theft. Meanwhile, organizations struggle to implement secure, user-friendly authentication systems that balance convenience with robust protection. This white paper examines how passkeys, a modern, password-less authentication standard developed by the FIDO Alliance, can address these challenges by offering an ecosystem of more secure and scalable solution for digital authentication.
Passkeys utilize public-key cryptography to securely store private keys on user devices, eliminating the reliance on easily compromised passwords. By using biometrics or PINs for local authentication, passkeys offer a secure, user-friendly alternative that is resilient against phishing, credential theft, and replay attacks. This paper delves into the technical framework of passkeys, emphasizing their seamless integration across platforms and devices, making them an ideal solution for modern, cross-platform environments.
Key benefits include enhanced security, simplified login processes, and better user experience without sacrificing convenience.
Ultimately, adopting passkeys represents a strategic move towards a future-proof authentication model, aligning with zero-trust principles and regulatory requirements. Organizations that embrace passkeys will not only mitigate password related security risks but also reduce operational costs and build greater trust in digital interactions.
Current Landscape: Authentication Methods and Challenges
Authentication technologies serve as the first line of defense against unauthorized access, fraud, and data breaches. With the rise in cyberattacks, the increasing complexity of regulatory compliance requirements, and user demand for seamless digital experiences, authentication systems have had to adapt rapidly. These pressures have led to the development of a variety of advanced authentication methods to ensure that users can access services securely without compromising their experience.
This brings us to an important question: What are the current authentication technologies?
Password-less Authentication
Emerging as alternatives to passwords, below password-less methods prioritize convenience and security:
Biometrics
Fingerprint, face, and voice recognition leverage unique physiological traits for authentication. While user-friendly, biometrics raise privacy concerns, require specialized hardware, and remain susceptible to spoofing (e.g. deepfakes or fingerprint replicas).
Magic Links/OTPs
Users receive a time-sensitive URL/code via email or SMS to log in. Though simple, these depend on email/SMS security, which are frequent targets for interception, phishing and SIM swapping attacks.
Authenticator Apps
Apps like Microsoft Authenticator send approval requests to a user’s device. This method reduces phishing risks but requires a secondary device.
The Path Forward
While innovations like biometrics represent progress, no single method fully balances security, usability, and scalability. The proliferation of devices and evolving cyber threats demand a unified, resilient approach, a gap that passkeys aim to bridge. Before we dive into passkeys, it's important to first understand a few key terms.
Figure 1. FIDO2
Authenticator
A device or software capable of securely storing cryptographic keys and performing authentication operations. These can be either roaming which are portable and can be used across multiple devices for e.g. YubiKey or platform that are tied to that specific platform like iCloud keychain.
WebAuthN
A W3C standard that enables secure, password-less authentication to websites and web applications. It defines how websites can interact with authenticators. It has a browser and platform API that enables servers to register and authenticate users using public-key cryptography instead of passwords. This forms the technical foundation for passkeys.
CTAP (Client-to-Authenticator Protocol)
This standard defines the communication protocol between a client device (like a computer or phone) and an external authenticator (like a security key) over various interfaces such as USB, Bluetooth, or NFC.
FIDO2
This is an open standard for strong authentication that encompasses both WebAuthN (for web-based authentication) and CTAP (for communication with authenticators). It aims to replace passwords with more secure and user-friendly methods.
Passkey
A discoverable FIDO2 credential based on public-key cryptography that is securely stored on a user's authenticator. It is unique to a specific website or application and offers a more secure and convenient alternative to traditional passwords.
FIDO Alliance (Fast Identity Online)
This is an industry consortium that develops and promotes open standards for authentication, including FIDO2, WebAuthN, and CTAP, with the goal of making online authentication stronger and simpler. FIDO’s mission is to create an ecosystem where password-less authentication works seamlessly across platforms, devices, and services.
Arrival of Passkeys
Technologies like WebAuthN, while revolutionary in providing password-less authentication, lacked these key features that hindered its widespread adoption.
- Lack of Native Cross-Device Support
- Absence of Key Syncing and Backup
- Limited Roaming Authenticator Standards
- No Ecosystem for Multi-Device Authentication
- User Experience Inconsistencies
The FIDO Alliance addressed these gaps in WebAuthN by expanding its capabilities through various initiatives.
CTAP: Bridging Devices and Authenticators
The Client-to-Authenticator Protocol (CTAP) standardized communication between devices (e.g. laptops) and external authenticators (e.g. smartphones, security keys) via USB or Bluetooth. This enabled cross-device authentication, such as using a phone to log into a desktop browser.
Multi-Device FIDO (Passkeys)
FIDO’s discoverable credentials (resident keys) allowed cryptographic keys to be stored in encrypted, syncable cloud vaults (e.g. iCloud Keychain). This made it possible for users to access passkeys across devices, ensuring secure backup and recovery.
Standardized Attestation and Metadata
FIDO defined attestation formats to verify the authenticity of security keys (e.g. confirming a YubiKey is genuine). This increased enterprise confidence in the integrity of authentication hardware.
Ecosystem Alignment
FIDO worked with companies like Apple, Google, and Microsoft to standardize passkey implementations which resulted in cross-platform compatibility.
User Experience Guidelines
FIDO published the best practices for biometric prompts, PIN fallbacks, and error handling. These guidelines created consistent, intuitive authentication flows that enhanced user trust in password-less logins.
QR Code-Based Cross-Device Authentication
FIDO’s hybrid CTAP introduced QR code scanning to pair devices with Bluetooth or NFC. This expanded access to password-less logins, particularly in low-infrastructure environments.
Passkey Ceremonies
Passkey ceremonies are critical components of the passkey authentication process, consisting of two key phases.
Attestation
Attestation is a cryptographic mechanism that allows a relying party (e.g. a website or app) to verify the authenticity and security of the authenticator (the device or hardware generating passkeys).
It answers the question: “Is this passkey created by a trusted, secure device?”
We can think of attestation as a "digital certificate of authenticity" for your authentication hardware or software. For example, when registering a YubiKey, attestation proves it’s a genuine Yubico device, not a counterfeit.
Figure 2. Attestation Flow
As the user tries to create an account with the website the flow progresses as below
1. Relying Party Server initiates credential creation
The Relying Party Server sends a PublicKeyCredentialCreationOptions object to the Web Application which contains
- challenge: A cryptographically random value generated by the server to prevent replay attacks.
- rp: An object containing information about the Relying Party (website), such as its name and id (domain).
- user: An object containing information about the user being registered, such as their id (unique identifier) and name.
- pubKeyCredParams: An array specifying the cryptographic algorithms supported for key generation (e.g. ES256, RS256).
- attestation: A string indicating the desired type of attestation (e.g. "none", "indirect", "direct").
- excludeCredentials: An optional array of existing credentials for the same user on the same RP, to prevent duplicate registrations.
2. Web Application forwards request to the Authenticator via the Browser
The web application, utilizing the WebAuthN API within the browser, sends PublicKeyCredentialCreationOptions to the Authenticator which contains
- relying party id: The domain of the website.
- user info: The user's identifier.
- relying party info: other details about the RP.
- clientDataHash: A hash of the clientDataJSON that will be created by the browser. This binds the key generation to the specific registration request.
3. Authenticator creates a new key pair and attestation statement
The Authenticator performs user verification (e.g. via fingerprint scan, face recognition, or PIN) to confirm the user's presence and generates a new cryptographic key pair: a private key stored securely on the Authenticator and a public key.
- The Authenticator creates an attestation statement, which is a signed data structure.
- Contents of the Attestation Statement:
- Information about the Authenticator itself (e.g. manufacturer, model).
- Cryptographic information about the generated public key.
- A signature from the Authenticator's attestation key, verifying the authenticity of the statement.
- Certificate chain leading back to a trusted root of the Authenticator manufacturer.
4. Authenticator returns attestation information to the Browser as attestationObject
The Authenticator sends the attestationObject back to the browser which contains
- fmt: A string indicating the format of the attestation statement (e.g. "packed", "tpm").
- attStmt: The actual attestation statement (binary data).
- authData: Authenticator data, which includes:
- rpIdHash: A hash of the Relying Party ID.
- flags: Flags indicating various properties of the credential (e.g. user presence, user verification).
- signCount: A counter that increments with each use of the credential (important for preventing cloning).
- attestedCredentialData: Information about the newly created credential, including the credential ID and the public key.
5. Browser sends AuthenticatorAttestationResponse to the Relying Party Server
The browser constructs the AuthenticatorAttestationResponse and sends it to the Relying Party Server which contains
- clientDataJSON: A JSON string containing information about the client environment and the original challenge.
- attestationObject: The binary data received from the Authenticator.
6. Relying Party Server validates the attestation
The Relying Party Server receives the AuthenticatorAttestationResponse and performs validations
- Verify the challenge in clientDataJSON matches the one sent in PublicKeyCredentialCreationOptions.
- Verify the origin in clientDataJSON matches the Relying Party's expected origin.
- Hash the clientDataJSON and compare it to the clientDataHash sent to the Authenticator (implicitly done through the authData verification).
- Parse the attestationObject.
- Verify the rpIdHash in authData matches the Relying Party ID.
- Verify the flags in authData (e.g. user presence was asserted).
- Crucially, verify the attestation statement (attStmt) using the trusted attestation root certificates for the Authenticator's manufacturer. This confirms the Authenticator's genuineness.
- If attestation is successful, the server stores the credential ID, and the public key associated with the user for future authentication.
Assertion
Assertion is the cryptographic proof a user’s device (authenticator) generates during authentication to verify their identity. It is the digital equivalent of signing a document to confirm authenticity. When you log in with a passkey, the assertion is the signed data sent to the server, proving you hold the private key linked to your account.
Figure 3. Assertion Flow
As the user tries to login with the passkey created flow progresses as below
1. Relying Party Server initiates authentication with PublicKeyCredentialRequestOptions
The Relying Party Server sends a PublicKeyCredentialRequestOptions object to the Web Application to initiate the login process which contains
- challenge: A cryptographically random value generated by the server to prevent replay attacks.
- rpId: The Relying Party ID (domain).
- allowCredentials: An optional array of credential IDs that the user might use for authentication. This can help the browser suggest specific passkeys.
- userVerification: A string indicating whether user verification is required (("required", "preferred", "discouraged").
2. Web Application forwards request to the Authenticator via the Browser
The Web Application, using the WebAuthN API through the browser, sends the information below to the Authenticator. This is derived from PublicKeyCredentialRequestOptions
- relying party id: The domain of the website.
- clientDataHash: A hash of the clientDataJSON that will be created by the browser. This binds the assertion to the specific login request.
3. Authenticator performs user verification and creates the assertion
The Authenticator performs user verification (e.g. fingerprint, face recognition, PIN) to confirm the user's presence and consent which helps the Authenticator create the assertion, which is the signed challenge provided by the relying party server proving the user's control of the private key associated with the credential.
4. Authenticator returns assertion data and signature to the Browser
The Authenticator sends the following information back to the browser.
- authenticatorData: Authenticator data, which includes:
- rpIdHash: A hash of the Relying Party ID.
- flags: Flags indicating various properties of the authentication, such as user presence and user verification status.
- signCount: The current value of the sign counter for the credential.
- signature: The cryptographic signature generated by the Authenticator using the private key.
5. Browser sends AuthenticatorAssertionResponse to the Relying Party Server
The browser constructs the AuthenticatorAssertionResponse and sends it to the Relying Party Server which contains
- clientDataJSON: A JSON string containing information about the client environment and the original challenge.
- authenticatorData: The binary data received from the Authenticator (as described above).
- signature: The cryptographic signature received from the Authenticator.
6. Relying Party Server validates the assertion
The Relying Party Server receives the AuthenticatorAssertionResponse and performs validation to authenticate the user. The validation consists of the following steps
- Verify the challenge in clientDataJSON matches the one sent in PublicKeyCredentialRequestOptions.
- Verify the origin in clientDataJSON matches the Relying Party's expected origin.
- Hash the clientDataJSON and compare it to the clientDataHash sent to the Authenticator (implicitly done through authenticatorData verification).
- Verify the rpIdHash in authenticatorData matches the Relying Party ID.
- Verify the user presence flag in authenticatorData is set.
- If user verification was required, verify the user verification flag in authenticatorData is set.
- Crucially, verify the signature using the stored public key associated with the credential ID. This confirms that the assertion was created by the legitimate holder of the private key.
- Optionally, verify the signCount in authenticatorData to prevent replay attacks (ensuring it is greater than the last seen value).
- If all validations pass, the Relying Party Server authenticates the user and establishes a session.
The table below gives a brief overview of the differences between attestation and assertion
| Aspect | Attestation | Assertion |
|---|---|---|
| When It Occurs | During registration (account setup). | During authentication (login). |
| Purpose | Proves the authenticator’s trustworthiness (e.g. device/hardware). | Proves the user owns the private key linked to their account. |
| What It Verifies | This key was created by a secure, trusted device. | This user controls the private key for this account. |
| Cryptographic Focus | Validates the authenticator’s origin (e.g. YubiKey, iPhone). | Validates the user’s identity via a signed challenge. |
| Data Included |
|
|
Passkeys Benefits
Built on public-key cryptography and secure attestation/assertion processes, passkeys offer significant security advantages, including being:
Phishing Resistant
Passkeys are fundamentally resistant to phishing because they are cryptographically bound to the specific domain (the Relying Party ID) for which they were created. The browser, during the assertion process, ensures that the authentication request originates from the correct website. Even if a user is tricked into visiting a fake site, their passkey created for the legitimate service will not work on the fraudulent one. The browser simply won't offer it as an option. This eliminates the possibility of a user inadvertently providing their credentials to a malicious party.
Effective Defense Against Replay Attacks
The assertion process incorporates a unique, cryptographically random challenge provided by the Relying Party Server for each authentication attempt. This challenge is signed by the Authenticator using the private key. Because the challenge is unique to each login attempt, a captured assertion is useless for future authentication. The server will expect a different challenge to be signed, rendering replayed attempts invalid.
Secure on Public and Shared Devices
Passkeys are inherently safer to use on public devices because the private key material never leaves the user's personal Authenticator (e.g. their phone, laptop with a secure enclave, security key). Authentication relies on unlocking the Authenticator itself using biometrics or a device PIN, which are local and not transmitted to the public device or the website.
The public device acts merely as an intermediary, facilitating communication between the Authenticator and the Relying Party Server. Even if malware is present on the public device, it cannot access the user's private key. This significantly reduces the attack surface associated with using shared devices for online authentication.
Support for Multiple Passkeys and Authenticators: Enhancing Usability and Resilience
A key strength of passkey is its support for users having multiple passkeys associated with a single online account. These passkeys can reside on different authenticators, providing significant benefits in terms of usability and resilience given below:
- Redundancy and Recovery: If a user loses access to one of their authenticators (e.g. their primary phone is lost or damaged), they can still access their accounts using a passkey stored on another device (e.g. a tablet, a security key, or another phone). This significantly reduces the risk of account lockout and simplifies the recovery process compared to traditional methods, which often rely on cumbersome recovery emails or codes.
- Cross-Platform Compatibility: Users can leverage passkeys across different devices and platforms. A passkey created on a laptop can be used to log in on a mobile phone, and vice versa.
- Convenience: Users can choose the authenticator that is most convenient for them at the time of login. For example, they might use their phone's biometric sensor at home and a hardware security key when using a public computer.
- Enhanced Security Post-Compromise: If one authenticator is compromised, the user can revoke the associated passkey without losing access to their account, as they have other passkeys tied to different secure authenticators.
Conclusion
While the transition to a fully password-less world will take time, the fundamental security and usability benefits of passkeys position them as a cornerstone of future online interactions. Embracing this technology is not just about adopting a new login method; it's about building a more secure, convenient, and resilient digital ecosystem for everyone.
As the digital landscape continues to evolve, passkeys offer a powerful and practical solution to the enduring challenges of verifying identity online, paving the way for a more secure and seamless future.
References
Subscribe
To keep yourself updated on the latest technology and industry trends subscribe to the Infosys Knowledge Institute's publications
Count me in!