WebAuthn: Difference between revisions

Line 44:

It defines an [[API]] for websites to [[Authentication#In computer science|authenticate]] users using WebAuthn credentials ('''passkeys'''<ref>{{cite web |title=White Paper: Multi-Device FIDO Credentials |url=https://fidoalliance.org/wp-content/uploads/2022/03/How-FIDO-Addresses-a-Full-Range-of-Use-Cases-March24.pdf |publisher=[[FIDO Alliance]] |access-date=20 May 2024 |page=6 |date=March 2022}}</ref><ref name="docsrs-webauthnrs">{{cite web |last1=Brown |first1=William |title=webauthn-rs docs |url=https://docs.rs/webauthn-rs/latest/webauthn_rs/#what-is-a-passkey |website=Docs.rs |publisher=Kanidm Identity Management Project |access-date=3 July 2025 |date=April 2024 |archive-url=https://web.archive.org/web/20250612151121/https://docs.rs/webauthn-rs/latest/webauthn_rs/#what-is-a-passkey |archive-date=12 June 2025}}</ref>) and outlines what WebAuthn authenticators should do.

It solves many of the issues of traditional [[password]]-based authentication by verifying the user's identity with [[digital signatures]].<ref name="imperialviolet-webauthn">{{cite web |url=https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html |title=A Tour of WebAuthn}}</ref>

WebAuthn is often touted as a complete replacement for passwords, eliminating the need for passwords. However, most websites that support WebAuthn still ~~utilize~~ passwords in some way.<ref name="arstechnica-not-usable">{{cite web |last1=Goodin |first1=Dan |title=Passkey technology is elegant, but it’s most definitely not usable security |url=https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ |publisher=Ars Technica |access-date=3 July 2025}}</ref>

WebAuthn is often touted as a complete replacement for passwords, eliminating the need for passwords. However, most websites that support WebAuthn still use passwords in some way.<ref name="arstechnica-not-usable">{{cite web |last1=Goodin |first1=Dan |title=Passkey technology is elegant, but it’s most definitely not usable security |url=https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ |publisher=Ars Technica |access-date=3 July 2025}}</ref>

~~In order to~~ use WebAuthn, users require a compatible authenticator. The standard does not specify how the [[private key|keys]] required for signing ~~are to be stored~~, so a variety of authenticator types can be used. The most common authenticator type is a platform authenticator, which is built into the [[operating system]] of the device. Common platform authenticators include [[Android (operating system)|Android]], [[Apple Keychain]] and [[Windows Hello]]. These make use of hardware security features (such as [[trusted execution environment|TEE]] and [[Trusted Platform Module|TPM]]), and often sync credentials between devices for ease-of-use. Another common authenticator type is a roaming authenticator, where a separate hardware device authenticates the user by connecting over [[USB]], [[Bluetooth Low Energy]], or [[near-field communications]] (NFC). Most [[smartphones]] can be used as roaming authenticators, and dedicated physical [[security token|security keys]] are also used. WebAuthn is effectively backward compatible with FIDO [[Universal 2nd Factor]] (U2F) as they both use the [[CTAP]] protocol.<ref>{{cite web |title=WebAuthn / CTAP: Modern Authentication |url=https://www.w3.org/Security/201812-Auth-ID/05_-_Day_1_-_Understanding_WebAuthn,_CTAP,_EAT,_FIDO_and_Authenticators.pdf |publisher=[[World Wide Web Consortium]] |access-date=11 March 2019 |date=10 December 2018}}</ref>

To use WebAuthn, users require a compatible authenticator. The standard does not specify how to store the [[private key|keys]] required for signing, so a variety of authenticator types can be used. The most common authenticator type is a platform authenticator, which is built into the [[operating system]] of the device. Common platform authenticators include [[Android (operating system)|Android]], [[Apple Keychain]] and [[Windows Hello]]. These make use of hardware security features (such as [[trusted execution environment|TEE]] and [[Trusted Platform Module|TPM]]), and often sync credentials between devices for ease-of-use. Another common authenticator type is a roaming authenticator, where a separate hardware device authenticates the user by connecting over [[USB]], [[Bluetooth Low Energy]], or [[near-field communications]] (NFC). Most [[smartphones]] can be used as roaming authenticators, and dedicated physical [[security token|security keys]] are also used. WebAuthn is effectively backward compatible with FIDO [[Universal 2nd Factor]] (U2F) as they both use the [[CTAP]] protocol.<ref>{{cite web |title=WebAuthn / CTAP: Modern Authentication |url=https://www.w3.org/Security/201812-Auth-ID/05_-_Day_1_-_Understanding_WebAuthn,_CTAP,_EAT,_FIDO_and_Authenticators.pdf |publisher=[[World Wide Web Consortium]] |access-date=11 March 2019 |date=10 December 2018}}</ref>

Like legacy U2F, WebAuthn is resistant to [[phishing|phishing attacks]]<ref>{{cite web |last1=Kan |first1=Michael |title=Google: Phishing Attacks That Can Beat Two-Factor Are on the Rise |url=https://www.pcmag.com/news/367026/google-phishing-attacks-that-can-beat-two-factor-are-on-the |publisher=PC Magazine |access-date=8 March 2019 |date=7 March 2019}}</ref> as the authenticator only offers credentials that were registered on the [[same-origin policy|same website]]. However, unlike U2F, WebAuthn can be implemented in a [[passwordless authentication|passwordless]] manner.<ref>{{Cite web |date=2018-04-10 |title=Practical passwordless authentication comes a step closer with WebAuthn |url=https://arstechnica.com/gadgets/2018/04/practical-passwordless-authentication-comes-a-step-closer-with-webauthn/ |access-date=2024-10-16 |website=[[Ars Technica]] |language=en-US}}</ref> Moreover, a roaming hardware authenticator ~~is resistant to~~ malware since the keys are stored on a separate device which prevents the malware from accessing them directly.

Like legacy U2F, WebAuthn is resistant to [[phishing|phishing attacks]]<ref>{{cite web |last1=Kan |first1=Michael |title=Google: Phishing Attacks That Can Beat Two-Factor Are on the Rise |url=https://www.pcmag.com/news/367026/google-phishing-attacks-that-can-beat-two-factor-are-on-the |publisher=PC Magazine |access-date=8 March 2019 |date=7 March 2019}}</ref> as the authenticator only offers credentials that were registered on the [[same-origin policy|same website]]. However, unlike U2F, WebAuthn can be implemented in a [[passwordless authentication|passwordless]] manner.<ref>{{Cite web |date=2018-04-10 |title=Practical passwordless authentication comes a step closer with WebAuthn |url=https://arstechnica.com/gadgets/2018/04/practical-passwordless-authentication-comes-a-step-closer-with-webauthn/ |access-date=2024-10-16 |website=[[Ars Technica]] |language=en-US}}</ref> Moreover, a roaming hardware authenticator resists malware, since the keys are stored on a separate device, which prevents the malware from accessing them directly.

The WebAuthn Level 1 and 2 standards were published as [[W3C recommendation|W3C Recommendations]] on 4 March 2019 and 8 April 2021 respectively.<ref name="W3C-WebAuthn-Level-1">{{cite web |editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Liao |editor7-first=Angelo |editor8-last=Lindemann |editor8-first=Rolf |editor9-last=Lundberg |editor9-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level 1 (latest) |url=https://www.w3.org/TR/webauthn-1/ |publisher=[[World Wide Web Consortium]] |access-date=4 March 2019}}</ref><ref name="W3C-WebAuthn-announce">{{cite web |title=W3C and FIDO Alliance Finalize Web Standard for Secure, Passwordless Logins |url=https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en |publisher=[[World Wide Web Consortium]] |access-date=4 March 2019 |date=4 March 2019}}</ref><ref name="W3C-WebAuthn-Level-2">{{cite web |editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Lindemann |editor7-first=Rolf |editor8-last=Lundberg |editor8-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level 2 |url=https://www.w3.org/TR/webauthn-2/ |access-date=27 November 2022 |publisher=[[World Wide Web Consortium]] |publication-date=8 April 2021 |edition=Latest}}</ref> A Level 3 specification is currently a ''First Public Working Draft'' (FPWD).<ref name="W3C-WebAuthn-Level-3">{{Cite web|editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Lindemann |editor7-first=Rolf |editor8-last=Lundberg |editor8-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level 3 |url=https://www.w3.org/TR/webauthn-3/ |publisher=[[World Wide Web Consortium]] |access-date=24 December 2021 |publication-date=4 April 2021|edition=First Public Working Draft}}</ref>

Line 59:

* ''something you are:'' a [[Biometrics|biometric]] such as fingerprint, iris or voice

Regardless of mode, the authenticator never shares its secrets or biometric data with the website.<ref>{{Cite web|url=https://www.w3.org/TR/webauthn/Overview.html#user-verification|title=Web Authentication: An API for accessing Public Key Credentials Level 1 § Terminology: User Verification|date=4 March 2019|website=www.w3.org|publisher=W3C|access-date=2019-06-16}}</ref> Moreover, a single user's secret or biometric works with all websites, as the authenticator ~~will select~~ the correct [[Public-key cryptography|cryptographic key material]] to use for the service requesting authentication after user verification was completed successfully.

Regardless of mode, the authenticator never shares its secrets or biometric data with the website.<ref>{{Cite web|url=https://www.w3.org/TR/webauthn/Overview.html#user-verification|title=Web Authentication: An API for accessing Public Key Credentials Level 1 § Terminology: User Verification|date=4 March 2019|website=www.w3.org|publisher=W3C|access-date=2019-06-16}}</ref> Moreover, a single user's secret or biometric works with all websites, as the authenticator selects the correct [[Public-key cryptography|cryptographic key material]] to use for the service requesting authentication after user verification was completed successfully.

A secret and biometric on the authenticator can be used together, similarly to how they would be used on a [[smartphone]]. For example, a fingerprint ~~is used to provide~~ convenient access to your smartphone but occasionally fingerprint access fails, in which case a PIN ~~can be used~~.

A secret and biometric on the authenticator can be used together, similarly to how they would be used on a [[smartphone]]. For example, a fingerprint provides convenient access to your smartphone, but occasionally fingerprint access fails, in which case you can use a PIN.

== Reasons for its design and standardization ==

~~WebAuthn was~~ designed and ~~standardised by the W3C in order~~ to solve or mitigate many inherent ~~issues with~~ traditional password-based authentication:

The W3C designed and standardized WebAuthn to solve or mitigate many issues that are inherent to traditional password-based authentication:

* Secure credential generation and storage: WebAuthn generates unique credentials for each website using robust algorithms, storing them securely in trusted authenticators. This eliminates common vulnerabilities such as:

Line 87:

* The website is a conforming WebAuthn Relying Party

* The browser is a conforming WebAuthn Client

* The authenticator is a FIDO2 authenticator, that is, it is assumed ~~to be~~ compatible with the WebAuthn Client

* The authenticator is a FIDO2 authenticator, that is, it is assumed compatible with the WebAuthn Client

WebAuthn specifies how a claimant demonstrates possession and control of a FIDO2 authenticator to a verifier called the WebAuthn Relying Party. The authentication process is mediated by an entity called the WebAuthn Client, which is little more than a conforming web browser.

Line 140:

In August 2018, Paragon Initiative Enterprises conducted a security audit of the WebAuthn standard. While they could not find any specific [[Exploit (computer security)|exploits]], they revealed some serious weaknesses in the way the underlying cryptography is used and mandated by the standard.<ref name="paragon-blog">{{cite web|url=https://paragonie.com/blog/2018/08/security-concerns-surrounding-webauthn-don-t-implement-ecdaa-yet|title=Security Concerns Surrounding WebAuthn: Don't Implement ECDAA (Yet)|publisher=Paragon Initiative Enterprises Blog|date=2018-08-23|access-date=2018-10-09}}</ref>

~~The main~~ points of criticism revolve around two potential issues that were problematic in other cryptographic systems in the past and therefore should be avoided in order to not fall victim to the same class of attacks:

Main points of criticism revolve around two potential issues that were problematic in other cryptographic systems in the past, and therefore should be avoided in order to not fall victim to the same class of attacks:

* Through the mandated use of [[CBOR Object Signing and Encryption|COSE]] ([[RFC:8152|RFC 8152]]) WebAuthn also supports [[RSA (cryptosystem)|RSA]] with [[PKCS 1|PKCS1v1.5 padding]]. This particular scheme of padding is known to be vulnerable to [[Adaptive chosen-ciphertext attack|specific attacks]] for at least twenty years and it has been successfully attacked in other protocols and implementations of the RSA cryptosystem in the past. It is difficult to exploit under ~~the~~ given conditions in the context of WebAuthn, but ~~given that~~ there are more secure cryptographic primitives and padding schemes, ~~this~~ is still a bad choice and is no longer ~~considered to be~~ best practice ~~among cryptographers~~.

* Through the mandated use of [[CBOR Object Signing and Encryption|COSE]] ([[RFC:8152|RFC 8152]]) WebAuthn also supports [[RSA (cryptosystem)|RSA]] with [[PKCS 1|PKCS1v1.5 padding]]. This particular scheme of padding has been known to be vulnerable to [[Adaptive chosen-ciphertext attack|specific attacks]] for at least twenty years, and it has been successfully attacked in other protocols and implementations of the RSA cryptosystem in the past. It is difficult to exploit under given conditions in the context of WebAuthn, but since there are more secure cryptographic primitives and padding schemes, it is still a bad choice and cryptographers no longer consider it best practice.

* The FIDO Alliance standardized on the [[public-key cryptography|asymmetric cryptographic]] scheme [[ECDAA]].<ref name="ecdaa-spec">{{cite web|url=https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html|title=FIDO ECDAA Algorithm|publisher=FIDO Alliance|date=2018-02-27|access-date=2018-10-09}}</ref> This is a version of [[Direct Anonymous Attestation|direct anonymous attestation]] based on [[elliptic curve]]s and in the case of WebAuthn is ~~meant to be~~ used to verify the integrity of authenticators, while also preserving the privacy of users, as it does not allow for global correlation of handles. However, ECDAA does not incorporate some of the lessons that were learned in the last decades of research in the area of [[Elliptic-curve cryptography|elliptic curve cryptography]], as the chosen curve has some security deficits inherent to this type of curve, which reduces the security guarantees quite substantially. Furthermore, the ECDAA standard involves random, non-deterministic signatures, which already has been a problem in the past.

* The FIDO Alliance standardized on the [[public-key cryptography|asymmetric cryptographic]] scheme [[ECDAA]].<ref name="ecdaa-spec">{{cite web|url=https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html|title=FIDO ECDAA Algorithm|publisher=FIDO Alliance|date=2018-02-27|access-date=2018-10-09}}</ref> This is a version of [[Direct Anonymous Attestation|direct anonymous attestation]] based on [[elliptic curve]]s and in the case of WebAuthn is used to verify the integrity of authenticators, while also preserving the privacy of users, as it does not allow for global correlation of handles. However, ECDAA does not incorporate some of the lessons that were learned in the last decades of research in the area of [[Elliptic-curve cryptography|elliptic curve cryptography]], as the chosen curve has some security deficits inherent to this type of curve, which reduces the security guarantees quite substantially. Furthermore, the ECDAA standard involves random, non-deterministic signatures, which already has been a problem in the past.

Paragon Initiative Enterprises also criticized how the standard was initially developed, as the proposal was not made public in advance and experienced cryptographers were not asked for suggestions and feedback. Hence the standard was not subject to broad cryptographic research from the academic world.

Line 149:

Despite these shortcomings, Paragon Initiative Enterprises still encourage users to continue to use WebAuthn but have come up with some recommendations for potential implementers and developers of the standard that they hope can be implemented before the standard is finalized. Avoiding such mistakes as early as possible would protect the industry from any challenges that are introduced by broken standards and the need for [[Backward compatibility|backwards compatibility]].

ECDAA was only designed to ~~be used~~ in combination with device attestation. This particular feature of WebAuthn is not necessarily required for authentication to work. Current implementations allow the user to decide whether an attestation statement is sent during the registration ceremony. Independently, relying parties can choose to require attestation or not. ECDAA was removed from WebAuthn Level 2 as it was not implemented by browsers nor relying parties.<ref>{{Cite web|date=2020-04-28|title=Remove ECDAA? · Issue #1410 · w3c/webauthn|url=https://github.com/w3c/webauthn/issues/1410|access-date=2020-06-03|website=GitHub|language=en}}</ref>

ECDAA was only designed to use in combination with device attestation. This particular feature of WebAuthn is not necessarily required for authentication to work. Current implementations allow the user to decide whether an attestation statement is sent during the registration ceremony. Independently, relying parties can choose to require attestation or not. ECDAA was removed from WebAuthn Level 2 as it was not implemented by browsers nor relying parties.<ref>{{Cite web|date=2020-04-28|title=Remove ECDAA? · Issue #1410 · w3c/webauthn|url=https://github.com/w3c/webauthn/issues/1410|access-date=2020-06-03|website=GitHub|language=en}}</ref>

== In the media ==

Line 165:

''Passkey'' is the [[de facto]] [[technical language|non-technical]] term for a WebAuthn credential.<ref name="docsrs-webauthnrs" /><ref name="imperialviolet-webauthn" /> It is widely used in situations where jargon is unhelpful, such as consumer marketing, and most user interfaces that support WebAuthn use only ''passkey'' to refer to WebAuthn credentials.<ref name="arstechnica-not-usable" />

When Apple first introduced passkeys to the public in 2022,<ref>{{cite news |last1=Clemons |first1=Taylor |title=WWDC 2022: Apple announces Passkey feature to eliminate passwords across platforms |url=https://www.zdnet.com/article/wwdc-2022-apple-announces-passkey-feature/ |access-date=4 July 2025 |publisher=ZD Net |date=6 June 2022}}</ref> they emphasized their first-party platform integrations. This, combined with the lack of clear communication from other industry leaders, led some to speculate that passkeys were proprietary to Apple (this was not the case).<ref>{{cite news |last1=Shakir |first1=Umar |title=Reminder: passkeys are not just from Apple |url=https://www.theverge.com/2022/8/5/23293643/apple-passkeys-fido-alliance-passwordless-google-microsoft |access-date=4 July 2025 |publisher=The Verge |date=6 August 2022}}</ref> As browsers and websites began to implement WebAuthn, the inconsistent feature-sets resulted in a variety of understandings of what exactly counted as a passkey. Some people assumed that a passkey ~~had to be managed~~ by a platform authenticator, or ~~that it had to be synchronized~~ using the cloud. A better definition is that a passkey is any WebAuthn credential managed by any WebAuthn authenticator.<ref name="docsrs-webauthnrs" /> This definition covers most of what different vendors refer to and accept as "passkeys".

When Apple first introduced passkeys to the public in 2022,<ref>{{cite news |last1=Clemons |first1=Taylor |title=WWDC 2022: Apple announces Passkey feature to eliminate passwords across platforms |url=https://www.zdnet.com/article/wwdc-2022-apple-announces-passkey-feature/ |access-date=4 July 2025 |publisher=ZD Net |date=6 June 2022}}</ref> they emphasized their first-party platform integrations. This, combined with the lack of clear communication from other industry leaders, led some to speculate that passkeys were proprietary to Apple (this was not the case).<ref>{{cite news |last1=Shakir |first1=Umar |title=Reminder: passkeys are not just from Apple |url=https://www.theverge.com/2022/8/5/23293643/apple-passkeys-fido-alliance-passwordless-google-microsoft |access-date=4 July 2025 |publisher=The Verge |date=6 August 2022}}</ref> As browsers and websites began to implement WebAuthn, the inconsistent feature-sets resulted in a variety of understandings of what exactly counted as a passkey. Some people assumed that a passkey required management by a platform authenticator, or needed synchronization using the cloud. A better definition is that a passkey is any WebAuthn credential managed by any WebAuthn authenticator.<ref name="docsrs-webauthnrs" /> This definition covers most of what different vendors refer to and accept as ''passkeys''.

== See also ==

@@ Line 44: / Line 44: @@
 It defines an [[API]] for websites to [[Authentication#In computer science|authenticate]] users using WebAuthn credentials ('''passkeys'''<ref>{{cite web |title=White Paper: Multi-Device FIDO Credentials |url=https://fidoalliance.org/wp-content/uploads/2022/03/How-FIDO-Addresses-a-Full-Range-of-Use-Cases-March24.pdf |publisher=[[FIDO Alliance]] |access-date=20 May 2024 |page=6 |date=March 2022}}</ref><ref name="docsrs-webauthnrs">{{cite web |last1=Brown |first1=William |title=webauthn-rs docs |url=https://docs.rs/webauthn-rs/latest/webauthn_rs/#what-is-a-passkey |website=Docs.rs |publisher=Kanidm Identity Management Project |access-date=3 July 2025 |date=April 2024 |archive-url=https://web.archive.org/web/20250612151121/https://docs.rs/webauthn-rs/latest/webauthn_rs/#what-is-a-passkey |archive-date=12 June 2025}}</ref>) and outlines what WebAuthn authenticators should do.
 It solves many of the issues of traditional [[password]]-based authentication by verifying the user's identity with [[digital signatures]].<ref name="imperialviolet-webauthn">{{cite web |url=https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html |title=A Tour of WebAuthn}}</ref>
-WebAuthn is often touted as a complete replacement for passwords, eliminating the need for passwords. However, most websites that support WebAuthn still utilize passwords in some way.<ref name="arstechnica-not-usable">{{cite web |last1=Goodin |first1=Dan |title=Passkey technology is elegant, but it’s most definitely not usable security |url=https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ |publisher=Ars Technica |access-date=3 July 2025}}</ref>
+WebAuthn is often touted as a complete replacement for passwords, eliminating the need for passwords. However, most websites that support WebAuthn still use passwords in some way.<ref name="arstechnica-not-usable">{{cite web |last1=Goodin |first1=Dan |title=Passkey technology is elegant, but it’s most definitely not usable security |url=https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ |publisher=Ars Technica |access-date=3 July 2025}}</ref>
-In order to use WebAuthn, users require a compatible authenticator. The standard does not specify how the [[private key|keys]] required for signing are to be stored, so a variety of authenticator types can be used. The most common authenticator type is a platform authenticator, which is built into the [[operating system]] of the device. Common platform authenticators include [[Android (operating system)|Android]], [[Apple Keychain]] and [[Windows Hello]]. These make use of hardware security features (such as [[trusted execution environment|TEE]] and [[Trusted Platform Module|TPM]]), and often sync credentials between devices for ease-of-use. Another common authenticator type is a roaming authenticator, where a separate hardware device authenticates the user by connecting over [[USB]], [[Bluetooth Low Energy]], or [[near-field communications]] (NFC). Most [[smartphones]] can be used as roaming authenticators, and dedicated physical [[security token|security keys]] are also used. WebAuthn is effectively backward compatible with FIDO [[Universal 2nd Factor]] (U2F) as they both use the [[CTAP]] protocol.<ref>{{cite web |title=WebAuthn / CTAP: Modern Authentication |url=https://www.w3.org/Security/201812-Auth-ID/05_-_Day_1_-_Understanding_WebAuthn,_CTAP,_EAT,_FIDO_and_Authenticators.pdf |publisher=[[World Wide Web Consortium]] |access-date=11 March 2019 |date=10 December 2018}}</ref>
+To use WebAuthn, users require a compatible authenticator. The standard does not specify how to store the [[private key|keys]] required for signing, so a variety of authenticator types can be used. The most common authenticator type is a platform authenticator, which is built into the [[operating system]] of the device. Common platform authenticators include [[Android (operating system)|Android]], [[Apple Keychain]] and [[Windows Hello]]. These make use of hardware security features (such as [[trusted execution environment|TEE]] and [[Trusted Platform Module|TPM]]), and often sync credentials between devices for ease-of-use. Another common authenticator type is a roaming authenticator, where a separate hardware device authenticates the user by connecting over [[USB]], [[Bluetooth Low Energy]], or [[near-field communications]] (NFC). Most [[smartphones]] can be used as roaming authenticators, and dedicated physical [[security token|security keys]] are also used. WebAuthn is effectively backward compatible with FIDO [[Universal 2nd Factor]] (U2F) as they both use the [[CTAP]] protocol.<ref>{{cite web |title=WebAuthn / CTAP: Modern Authentication |url=https://www.w3.org/Security/201812-Auth-ID/05_-_Day_1_-_Understanding_WebAuthn,_CTAP,_EAT,_FIDO_and_Authenticators.pdf |publisher=[[World Wide Web Consortium]] |access-date=11 March 2019 |date=10 December 2018}}</ref>
-Like legacy U2F, WebAuthn is resistant to [[phishing|phishing attacks]]<ref>{{cite web |last1=Kan |first1=Michael |title=Google: Phishing Attacks That Can Beat Two-Factor Are on the Rise |url=https://www.pcmag.com/news/367026/google-phishing-attacks-that-can-beat-two-factor-are-on-the |publisher=PC Magazine |access-date=8 March 2019 |date=7 March 2019}}</ref> as the authenticator only offers credentials that were registered on the [[same-origin policy|same website]]. However, unlike U2F, WebAuthn can be implemented in a [[passwordless authentication|passwordless]] manner.<ref>{{Cite web |date=2018-04-10 |title=Practical passwordless authentication comes a step closer with WebAuthn |url=https://arstechnica.com/gadgets/2018/04/practical-passwordless-authentication-comes-a-step-closer-with-webauthn/ |access-date=2024-10-16 |website=[[Ars Technica]] |language=en-US}}</ref> Moreover, a roaming hardware authenticator is resistant to malware since the keys are stored on a separate device which prevents the malware from accessing them directly.
+Like legacy U2F, WebAuthn is resistant to [[phishing|phishing attacks]]<ref>{{cite web |last1=Kan |first1=Michael |title=Google: Phishing Attacks That Can Beat Two-Factor Are on the Rise |url=https://www.pcmag.com/news/367026/google-phishing-attacks-that-can-beat-two-factor-are-on-the |publisher=PC Magazine |access-date=8 March 2019 |date=7 March 2019}}</ref> as the authenticator only offers credentials that were registered on the [[same-origin policy|same website]]. However, unlike U2F, WebAuthn can be implemented in a [[passwordless authentication|passwordless]] manner.<ref>{{Cite web |date=2018-04-10 |title=Practical passwordless authentication comes a step closer with WebAuthn |url=https://arstechnica.com/gadgets/2018/04/practical-passwordless-authentication-comes-a-step-closer-with-webauthn/ |access-date=2024-10-16 |website=[[Ars Technica]] |language=en-US}}</ref> Moreover, a roaming hardware authenticator resists malware, since the keys are stored on a separate device, which prevents the malware from accessing them directly.
 The WebAuthn Level&nbsp;1 and 2 standards were published as [[W3C recommendation|W3C Recommendations]] on 4 March 2019 and 8 April 2021 respectively.<ref name="W3C-WebAuthn-Level-1">{{cite web |editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Liao |editor7-first=Angelo |editor8-last=Lindemann |editor8-first=Rolf |editor9-last=Lundberg |editor9-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level&nbsp;1 (latest) |url=https://www.w3.org/TR/webauthn-1/ |publisher=[[World Wide Web Consortium]] |access-date=4 March 2019}}</ref><ref name="W3C-WebAuthn-announce">{{cite web |title=W3C and FIDO Alliance Finalize Web Standard for Secure, Passwordless Logins |url=https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en |publisher=[[World Wide Web Consortium]] |access-date=4 March 2019 |date=4 March 2019}}</ref><ref name="W3C-WebAuthn-Level-2">{{cite web |editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Lindemann |editor7-first=Rolf |editor8-last=Lundberg |editor8-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level&nbsp;2 |url=https://www.w3.org/TR/webauthn-2/ |access-date=27 November 2022 |publisher=[[World Wide Web Consortium]] |publication-date=8 April 2021 |edition=Latest}}</ref> A Level 3 specification is currently a ''First Public Working Draft'' (FPWD).<ref name="W3C-WebAuthn-Level-3">{{Cite web|editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Lindemann |editor7-first=Rolf |editor8-last=Lundberg |editor8-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level 3 |url=https://www.w3.org/TR/webauthn-3/ |publisher=[[World Wide Web Consortium]] |access-date=24 December 2021 |publication-date=4 April 2021|edition=First Public Working Draft}}</ref>
@@ Line 59: / Line 59: @@
 * ''something you are:'' a [[Biometrics|biometric]] such as fingerprint, iris or voice
-Regardless of mode, the authenticator never shares its secrets or biometric data with the website.<ref>{{Cite web|url=https://www.w3.org/TR/webauthn/Overview.html#user-verification|title=Web Authentication: An API for accessing Public Key Credentials Level 1 § Terminology: User Verification|date=4 March 2019|website=www.w3.org|publisher=W3C|access-date=2019-06-16}}</ref> Moreover, a single user's secret or biometric works with all websites, as the authenticator will select the correct [[Public-key cryptography|cryptographic key material]] to use for the service requesting authentication after user verification was completed successfully.
+Regardless of mode, the authenticator never shares its secrets or biometric data with the website.<ref>{{Cite web|url=https://www.w3.org/TR/webauthn/Overview.html#user-verification|title=Web Authentication: An API for accessing Public Key Credentials Level 1 § Terminology: User Verification|date=4 March 2019|website=www.w3.org|publisher=W3C|access-date=2019-06-16}}</ref> Moreover, a single user's secret or biometric works with all websites, as the authenticator selects the correct [[Public-key cryptography|cryptographic key material]] to use for the service requesting authentication after user verification was completed successfully.
-A secret and biometric on the authenticator can be used together, similarly to how they would be used on a [[smartphone]]. For example, a fingerprint is used to provide convenient access to your smartphone but occasionally fingerprint access fails, in which case a PIN can be used.
+A secret and biometric on the authenticator can be used together, similarly to how they would be used on a [[smartphone]]. For example, a fingerprint provides convenient access to your smartphone, but occasionally fingerprint access fails, in which case you can use a PIN.
 == Reasons for its design and standardization ==
-WebAuthn was designed and standardised by the W3C in order to solve or mitigate many inherent issues with traditional password-based authentication:
+The W3C designed and standardized WebAuthn to solve or mitigate many issues that are inherent to traditional password-based authentication:
 * Secure credential generation and storage: WebAuthn generates unique credentials for each website using robust algorithms, storing them securely in trusted authenticators. This eliminates common vulnerabilities such as:
@@ Line 87: / Line 87: @@
 * The website is a conforming WebAuthn Relying Party
 * The browser is a conforming WebAuthn Client
-* The authenticator is a FIDO2 authenticator, that is, it is assumed to be compatible with the WebAuthn Client
+* The authenticator is a FIDO2 authenticator, that is, it is assumed compatible with the WebAuthn Client
 WebAuthn specifies how a claimant demonstrates possession and control of a FIDO2 authenticator to a verifier called the WebAuthn Relying Party. The authentication process is mediated by an entity called the WebAuthn Client, which is little more than a conforming web browser.
@@ Line 140: / Line 140: @@
 In August 2018, Paragon Initiative Enterprises conducted a security audit of the WebAuthn standard. While they could not find any specific [[Exploit (computer security)|exploits]], they revealed some serious weaknesses in the way the underlying cryptography is used and mandated by the standard.<ref name="paragon-blog">{{cite web|url=https://paragonie.com/blog/2018/08/security-concerns-surrounding-webauthn-don-t-implement-ecdaa-yet|title=Security Concerns Surrounding WebAuthn: Don't Implement ECDAA (Yet)|publisher=Paragon Initiative Enterprises Blog|date=2018-08-23|access-date=2018-10-09}}</ref>
-The main points of criticism revolve around two potential issues that were problematic in other cryptographic systems in the past and therefore should be avoided in order to not fall victim to the same class of attacks:
+Main points of criticism revolve around two potential issues that were problematic in other cryptographic systems in the past, and therefore should be avoided in order to not fall victim to the same class of attacks:
-* Through the mandated use of [[CBOR Object Signing and Encryption|COSE]] ([[RFC:8152|RFC&nbsp;8152]]) WebAuthn also supports [[RSA (cryptosystem)|RSA]] with [[PKCS 1|PKCS1v1.5 padding]]. This particular scheme of padding is known to be vulnerable to [[Adaptive chosen-ciphertext attack|specific attacks]] for at least twenty years and it has been successfully attacked in other protocols and implementations of the RSA cryptosystem in the past. It is difficult to exploit under the given conditions in the context of WebAuthn, but given that there are more secure cryptographic primitives and padding schemes, this is still a bad choice and is no longer considered to be best practice among cryptographers.
+* Through the mandated use of [[CBOR Object Signing and Encryption|COSE]] ([[RFC:8152|RFC&nbsp;8152]]) WebAuthn also supports [[RSA (cryptosystem)|RSA]] with [[PKCS 1|PKCS1v1.5 padding]]. This particular scheme of padding has been known to be vulnerable to [[Adaptive chosen-ciphertext attack|specific attacks]] for at least twenty years, and it has been successfully attacked in other protocols and implementations of the RSA cryptosystem in the past. It is difficult to exploit under given conditions in the context of WebAuthn, but since there are more secure cryptographic primitives and padding schemes, it is still a bad choice and cryptographers no longer consider it best practice.
-* The FIDO Alliance standardized on the [[public-key cryptography|asymmetric cryptographic]] scheme [[ECDAA]].<ref name="ecdaa-spec">{{cite web|url=https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html|title=FIDO ECDAA Algorithm|publisher=FIDO Alliance|date=2018-02-27|access-date=2018-10-09}}</ref> This is a version of [[Direct Anonymous Attestation|direct anonymous attestation]] based on [[elliptic curve]]s and in the case of WebAuthn is meant to be used to verify the integrity of authenticators, while also preserving the privacy of users, as it does not allow for global correlation of handles. However, ECDAA does not incorporate some of the lessons that were learned in the last decades of research in the area of [[Elliptic-curve cryptography|elliptic curve cryptography]], as the chosen curve has some security deficits inherent to this type of curve, which reduces the security guarantees quite substantially. Furthermore, the ECDAA standard involves random, non-deterministic signatures, which already has been a problem in the past.
+* The FIDO Alliance standardized on the [[public-key cryptography|asymmetric cryptographic]] scheme [[ECDAA]].<ref name="ecdaa-spec">{{cite web|url=https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html|title=FIDO ECDAA Algorithm|publisher=FIDO Alliance|date=2018-02-27|access-date=2018-10-09}}</ref> This is a version of [[Direct Anonymous Attestation|direct anonymous attestation]] based on [[elliptic curve]]s and in the case of WebAuthn is used to verify the integrity of authenticators, while also preserving the privacy of users, as it does not allow for global correlation of handles. However, ECDAA does not incorporate some of the lessons that were learned in the last decades of research in the area of [[Elliptic-curve cryptography|elliptic curve cryptography]], as the chosen curve has some security deficits inherent to this type of curve, which reduces the security guarantees quite substantially. Furthermore, the ECDAA standard involves random, non-deterministic signatures, which already has been a problem in the past.
 Paragon Initiative Enterprises also criticized how the standard was initially developed, as the proposal was not made public in advance and experienced cryptographers were not asked for suggestions and feedback. Hence the standard was not subject to broad cryptographic research from the academic world.
@@ Line 149: / Line 149: @@
 Despite these shortcomings, Paragon Initiative Enterprises still encourage users to continue to use WebAuthn but have come up with some recommendations for potential implementers and developers of the standard that they hope can be implemented before the standard is finalized. Avoiding such mistakes as early as possible would protect the industry from any challenges that are introduced by broken standards and the need for [[Backward compatibility|backwards compatibility]].
-ECDAA was only designed to be used in combination with device attestation. This particular feature of WebAuthn is not necessarily required for authentication to work. Current implementations allow the user to decide whether an attestation statement is sent during the registration ceremony. Independently, relying parties can choose to require attestation or not. ECDAA was removed from WebAuthn Level 2 as it was not implemented by browsers nor relying parties.<ref>{{Cite web|date=2020-04-28|title=Remove ECDAA? · Issue #1410 · w3c/webauthn|url=https://github.com/w3c/webauthn/issues/1410|access-date=2020-06-03|website=GitHub|language=en}}</ref>
+ECDAA was only designed to use in combination with device attestation. This particular feature of WebAuthn is not necessarily required for authentication to work. Current implementations allow the user to decide whether an attestation statement is sent during the registration ceremony. Independently, relying parties can choose to require attestation or not. ECDAA was removed from WebAuthn Level 2 as it was not implemented by browsers nor relying parties.<ref>{{Cite web|date=2020-04-28|title=Remove ECDAA? · Issue #1410 · w3c/webauthn|url=https://github.com/w3c/webauthn/issues/1410|access-date=2020-06-03|website=GitHub|language=en}}</ref>
 == In the media ==
@@ Line 165: / Line 165: @@
 ''Passkey'' is the [[de facto]] [[technical language|non-technical]] term for a WebAuthn credential.<ref name="docsrs-webauthnrs" /><ref name="imperialviolet-webauthn" /> It is widely used in situations where jargon is unhelpful, such as consumer marketing, and most user interfaces that support WebAuthn use only ''passkey'' to refer to WebAuthn credentials.<ref name="arstechnica-not-usable" />
-When Apple first introduced passkeys to the public in 2022,<ref>{{cite news |last1=Clemons |first1=Taylor |title=WWDC 2022: Apple announces Passkey feature to eliminate passwords across platforms |url=https://www.zdnet.com/article/wwdc-2022-apple-announces-passkey-feature/ |access-date=4 July 2025 |publisher=ZD Net |date=6 June 2022}}</ref> they emphasized their first-party platform integrations. This, combined with the lack of clear communication from other industry leaders, led some to speculate that passkeys were proprietary to Apple (this was not the case).<ref>{{cite news |last1=Shakir |first1=Umar |title=Reminder: passkeys are not just from Apple |url=https://www.theverge.com/2022/8/5/23293643/apple-passkeys-fido-alliance-passwordless-google-microsoft |access-date=4 July 2025 |publisher=The Verge |date=6 August 2022}}</ref> As browsers and websites began to implement WebAuthn, the inconsistent feature-sets resulted in a variety of understandings of what exactly counted as a passkey. Some people assumed that a passkey had to be managed by a platform authenticator, or that it had to be synchronized using the cloud. A better definition is that a passkey is any WebAuthn credential managed by any WebAuthn authenticator.<ref name="docsrs-webauthnrs" /> This definition covers most of what different vendors refer to and accept as "passkeys".
+When Apple first introduced passkeys to the public in 2022,<ref>{{cite news |last1=Clemons |first1=Taylor |title=WWDC 2022: Apple announces Passkey feature to eliminate passwords across platforms |url=https://www.zdnet.com/article/wwdc-2022-apple-announces-passkey-feature/ |access-date=4 July 2025 |publisher=ZD Net |date=6 June 2022}}</ref> they emphasized their first-party platform integrations. This, combined with the lack of clear communication from other industry leaders, led some to speculate that passkeys were proprietary to Apple (this was not the case).<ref>{{cite news |last1=Shakir |first1=Umar |title=Reminder: passkeys are not just from Apple |url=https://www.theverge.com/2022/8/5/23293643/apple-passkeys-fido-alliance-passwordless-google-microsoft |access-date=4 July 2025 |publisher=The Verge |date=6 August 2022}}</ref> As browsers and websites began to implement WebAuthn, the inconsistent feature-sets resulted in a variety of understandings of what exactly counted as a passkey. Some people assumed that a passkey required management by a platform authenticator, or needed synchronization using the cloud. A better definition is that a passkey is any WebAuthn credential managed by any WebAuthn authenticator.<ref name="docsrs-webauthnrs" /> This definition covers most of what different vendors refer to and accept as ''passkeys''.
 == See also ==

WebAuthn: Difference between revisions

192.184.205.19 (talk)