View source for WebAuthn

{{Technical|date=February 2024}}
{{short description|Public-key authentication standard}}
{{Use dmy dates|date=October 2023}}
{{Infobox technology standard
| title = Web Authentication
| image             =
| caption           =
| year_started =
| first_published = {{Start date|2016|05|31|df=y}}
| version = Level 2 Recommendation
| version_date = {{Start date|2021|04|21|df=y}}
| organization = [[FIDO2 Project]] ([[FIDO Alliance]] and [[World Wide Web Consortium|W3C]])
| editors = {{Collapsible list|title=Current editors
|Jeff Hodges (Google)
|J.C. Jones (Mozilla)
|Michael B. Jones (Microsoft)
|Akshay Kumar (Microsoft)
|Emil Lundberg (Yubico)
}}
{{Collapsible list|title=Previous editors
|Dirk Balfanz (Google)
|Vijay Bharadwaj (Microsoft)
|Arnar Birgisson (Google)
|Alexei Czeskis (Google)
|Hubert Le Van Gong (PayPal)
|Angelo Liao (Microsoft)
|Rolf Lindemann (Nok Nok Labs)
}}
| domain = [[Authentication]]
| committee = [[Web Authentication Working Group]]
| abbreviation = WebAuthn
| preview = Level 3 ({{abbr|FPWD|First Public Working Draft}})
| preview_date = {{Start date|2021|12|15|df=y}}
| base_standards = {{Plainlist|
* [[HTML5 File API|File API]]
* WHATWG Encoding Standard
* Unicode AUX #29: Text Segmentation
}}
}}
'''Web Authentication''' ('''WebAuthn''') is a [[web standard]] published by the [[World Wide Web Consortium]] (W3C).<ref name="W3C-WebAuthn-Level-1"/><ref>{{cite web |url=https://www.w3.org/blog/webauthn/ |title=Web Authentication Working Group |publisher=[[World Wide Web Consortium]] |access-date=2018-05-11}}</ref><ref>{{cite episode |title=What is WebAuthn |series=TechStuff |publisher=[[iHeartMedia]] |series-link=HowStuffWorks#TechStuff |first=Jonathan |last=Strickland |date=18 March 2019 |url=https://www.iheart.com/podcast/105-techstuff-26941194/episode/what-is-webauthn-30705004/ |minutes=20:35 |access-date=20 March 2019}}</ref> WebAuthn is a core component of the [[FIDO Alliance#FIDO2|FIDO2 Project]] under the guidance of the [[FIDO Alliance]].<ref name="fido2">{{cite web|url=https://fidoalliance.org/fido2/|title=FIDO2 Project|publisher=FIDO Alliance|access-date=2018-05-11}}</ref> The goal of the project is to standardize an interface for authenticating users to web-based applications and services using [[public-key cryptography]]. WebAuthn credentials (which are themselves FIDO credentials) that are available across multiple devices are commonly referred to as '''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 |format=PDF |date=March 2022}}</ref>
On the client side, support for WebAuthn can be implemented in a variety of ways. The underlying cryptographic operations are performed by an [[authenticator]], which is an abstract functional model that is mostly agnostic with respect to how the key material is managed. This makes it possible to implement support for WebAuthn purely in software, making use of a processor's [[trusted execution environment]] or a [[Trusted Platform Module]] (TPM). Sensitive cryptographic operations can also be offloaded to a roaming hardware authenticator that can in turn be accessed via [[USB]], [[Bluetooth Low Energy]], or [[near-field communication]]s (NFC). A roaming hardware authenticator conforms to the FIDO [[Client to Authenticator Protocol]] (CTAP),<ref name="FIDO-CTAP">{{cite web |editor1-last=Brand |editor1-first=Christiaan |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Ehrensvärd |editor3-first=Jakob |editor4-last=Jones |editor4-first=Michael B. |editor5-last=Kumar |editor5-first=Akshay |editor6-last=Lindemann |editor6-first=Rolf |editor7-last=Powers |editor7-first=Adam |editor8-last=Verrept |editor8-first=Johan |title=Client to Authenticator Protocol (CTAP) |url=https://fidoalliance.org/specs/fido-v2.0-ps-20190130-pub/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html |publisher=FIDO Alliance |access-date=7 March 2019 |date=30 January 2019}}</ref> making WebAuthn effectively backward compatible with the FIDO [[Universal 2nd Factor]] (U2F) standard.<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, Web Authentication is resilient to verifier impersonation; that is, it is resistant to 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> but unlike U2F, WebAuthn [[Passwordless authentication|does not require]] a traditional password.<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 private key material is at no time accessible to software running on the host machine.
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>
== Background ==
FIDO2 is the successor to FIDO Universal 2nd Factor (U2F). Whereas U2F only supports multi-factor mode, having been designed to strengthen existing username/password-based login flows, FIDO2 adds support for single-factor mode. In multi-factor mode, the authenticator is activated by a test of ''user presence'', which usually consists of a simple button push; no password is required. In single-factor mode, the authenticator (''something you have'') performs ''user verification''.<ref>{{cite web |title=User Presence vs User Verification |url=https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html |access-date=19 February 2024}}</ref> Depending on the authenticator capabilities, this can be:<ref>{{Cite web|url=https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-registry-v2.0-rd-20180702.html#user-verification-methods|title=FIDO Registry of Predefined Values|last1=Baghdasaryan|first1=Davit|last2=Hill|first2=Brad|date=2 July 2018|website=fidoalliance.org|publisher=FIDO Alliance|access-date=2019-06-16}}</ref>
* ''something you know:'' a secret such as a [[Personal identification number|PIN]], [[Password|passcode]] or swipe pattern
* ''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.
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.
== Advantages over traditional password-based authentication ==
WebAuthn addresses by design many inherent issues in 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:
** Weak passwords that can be easily brute-forced due to insufficient length.
** Predictable passwords vulnerable to dictionary attacks (e.g., "password", "12345678").
** Guessable passwords based on personal information (e.g., birthdates, addresses).
** Poor client-side password storage (e.g., written down, stored in phone contacts).
** Password reuse across multiple websites, as WebAuthn credentials are specific to individual websites by design.
** Inadequate server-mandated password requirements (e.g., overly lax or restrictive criteria, arbitrary maximum length limits, limited charsets).
** Restrictions preventing password manager auto-fill features.
* '''No Server-Side Credential Storage''': The private part of a credential is never stored on a server, eliminating risks and vulnerabilities such as:
** Insecure password storage in databases (e.g., plaintext or relying on weak hash-based algorithms/constructions).
** Database leaks exposing passwords.
** Mandatory, ineffective periodic password changes.
* '''Unique Credentials for Each Website''': WebAuthn ensures credentials are unique per website, eliminating the following risks and vulnerabilities:
** Credential stuffing attacks, where attackers use credentials from one data breach across multiple sites.
** Phishing attacks, as credentials cannot be reused or misapplied to different websites.
== Overview ==
Like its predecessor FIDO U2F, W3C Web Authentication (WebAuthn) involves a [[website]], a [[web browser]], and an authenticator:<ref name="W3C-WebAuthn-Level-1" />
* 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
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.
===Authentication===
[[File:Passwordless_Web_Authentication.svg|thumb|right|A typical Web Authentication (WebAuthn) flow]]
For the purposes of illustration, we assume the authenticator is a roaming hardware authenticator (see below for other options). In any case, the authenticator is a multi-factor [[Cryptography|cryptographic]] authenticator that uses [[Cryptography#Public-key cryptography|public-key cryptography]] to sign an authentication assertion targeted at the WebAuthn Relying Party. Assuming the authenticator uses a [[Personal identification number|PIN]] for user verification, the authenticator itself is ''something you have'' while the PIN is ''something you know''.
To initiate the WebAuthn authentication flow,<ref>{{cite web |url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |title=Web Authentication API  |at=Section [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API#Authentication Authentication] |publisher=[[Mozilla]] |access-date=18 March 2019}}</ref> the WebAuthn Relying Party indicates its intentions to the WebAuthn Client (i.e., the browser) via [[JavaScript]]. The WebAuthn Client communicates with the authenticator using a JavaScript [[API]] implemented in the browser. A roaming authenticator conforms to the FIDO [[Client to Authenticator Protocol]].
WebAuthn does not strictly require a roaming hardware authenticator. Alternatively, a software authenticator (e.g., implemented on a smartphone) or a platform authenticator (i.e., an authenticator implemented directly on the WebAuthn Client Device) may be used. Relevant examples of platform authenticators include [[Windows Hello]]<ref>{{cite web |last1=Simons |first1=Alex |title=Secure password-less sign-in for your Microsoft account using a security key or Windows Hello |url=https://www.microsoft.com/en-us/microsoft-365/blog/2018/11/20/sign-in-to-your-microsoft-account-without-a-password-using-windows-hello-or-a-security-key/ |publisher=[[Microsoft]] |access-date=6 March 2019 |date=20 November 2018}}</ref> and the [[Android (operating system)|Android operating system]].<ref>{{cite web |title=Android Now FIDO2 Certified, Accelerating Global Migration Beyond Passwords |url=https://fidoalliance.org/android-now-fido2-certified-accelerating-global-migration-beyond-passwords/ |publisher=[[FIDO Alliance]] |access-date=6 March 2019 |location=BARCELONA |date=25 February 2019}}</ref>
The illustrated flow relies on PIN-based user verification, which, in terms of usability, is only a modest improvement over ordinary password authentication. In practice, the use of [[biometric]]s for user verification can improve the usability of WebAuthn.{{Citation needed|date=March 2019}} The logistics behind biometrics are still poorly understood, however. There is a lingering misunderstanding among users that biometric data is transmitted over the network in the same manner as passwords, which is not the case.<ref>{{cite web |title=Touch ID and Beyond: Duo's Plans for WebAuthn |url=https://duo.com/blog/touchid-webauthn |publisher=Duo Security |access-date=8 March 2019 |date=5 March 2019}}</ref><ref>{{cite web |last1=Steele |first1=Nick |title=How WebAuthn aims to solve the password problem |url=https://www.helpnetsecurity.com/2019/02/27/webauthn-solve-password-problem/ |publisher=Help Net Security |access-date=8 March 2019 |date=27 February 2019}}</ref>
===Registration===
When the WebAuthn Relying Party receives the signed authentication assertion from the browser, the digital signature on the assertion is verified using a trusted public key for the user.
To obtain a public key for the user, the WebAuthn Relying Party initiates a WebAuthn registration flow<ref>{{cite web |url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |title=Web Authentication API  |at=Section [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API#Registration Registration] |publisher=[[Mozilla]] |access-date=18 March 2019}}</ref> that is similar to the authentication flow illustrated above. The primary difference is that the authenticator now signs an attestation statement with its attestation private key. The signed attestation statement contains a copy of the public key that the WebAuthn Relying Party ultimately uses to verify a signed authentication assertion. The attestation statement also contains metadata describing the authenticator itself.{{Citation needed|date=March 2019}}
The digital signature on the attestation statement is verified with the trusted attestation public key for that particular model of authenticator. How the WebAuthn Relying Party obtains its store of trusted attestation public keys is unspecified. One option is to use the FIDO metadata service.<ref>{{cite web |title=Metadata Service |url=https://fidoalliance.org/metadata/ |publisher=[[FIDO Alliance]] |access-date=18 March 2019}}</ref>
The attestation type specified in the JavaScript determines the trust model. For instance, an attestation type called self-attestation may be desired, for which the trust model is essentially [[trust on first use]].
== Support ==
[[File:Bitwarden Passkey window screenshot.png|thumb|Example of WebAuthn implementation ([[Bitwarden]] for [[Discord]] on [[Firefox]])]]
The WebAuthn Level&nbsp;1 standard was published as a W3C Recommendation by the [[Web Authentication Working Group]] on 4 March 2019.<ref name="W3C-WebAuthn-Level-1" /><ref name="W3C-WebAuthn-announce" /><ref>{{Cite web |url=https://venturebeat.com/2019/03/04/w3c-approves-webauthn-as-the-web-standard-for-password-free-logins/ |title=W3C Approves WebAuthn as the Web Standard for Password-Free Logins |last=Protalinski |first=Emil |date=4 March 2019}}</ref> WebAuthn is supported by [[Google Chrome]], [[Mozilla Firefox]], [[Microsoft Edge]], [[Safari (web browser)|Apple Safari]]<ref name="W3C-WebAuthn-announce" /> and [[Opera (web browser)|Opera]].<ref>{{cite web |title=Can I use Web Authentication API? |url=https://caniuse.com/#feat=webauthn |access-date=7 March 2019}}</ref>
The desktop version of Google Chrome has supported WebAuthn since version 67.<ref name="chrome-support">{{cite web |url=https://developers.google.com/web/updates/2018/05/webauthn |title=Enabling Strong Authentication with WebAuthn |first=Christiaan |last=Brand |website=Google Developers |date=2018-06-03 |access-date=2018-06-25}}</ref> Firefox, which had not fully supported the previous FIDO U2F standard, included and enabled WebAuthn in Firefox version 60, released on 9 May 2018.<ref>{{cite web |url=https://www.cnet.com/news/firefox-moves-browsers-into-the-post-password-future-with-webauthn/ |title=Firefox moves browsers into post-password future with WebAuthn tech |first=Stephen |last=Shankland |website=CNET |date=2018-05-09 |access-date=2018-05-11}}</ref> An early [[Windows Insider]] release of Microsoft Edge (Build 17682) implemented a version of WebAuthn that works with both [[Windows Hello]] as well as external security keys.<ref>{{cite web |url=https://blogs.windows.com/windowsexperience/2018/05/31/announcing-windows-10-insider-preview-build-17682/#oHYCS0GkF95OMzKH.97 |title=Announcing Windows 10 Insider Preview Build 17682 |author=Sarkar |display-authors=etal |publisher=Microsoft |date=2018-05-23 |access-date=2018-06-25}}</ref>
Existing FIDO U2F security keys are largely compatible with the WebAuthn standard, though WebAuthn added the ability to reference a unique per-account "user handle" identifier, which older authenticators are unable to store.<ref name="W3C-WebAuthn-Level-1" />
One of the first FIDO2-compatible [[authenticator]]s was the second-generation [[YubiKey|Security Key]] by Yubico, announced on 10 April 2018.<ref>{{cite press release |url=https://www.yubico.com/press-releases/280530/ |title=Yubico Launches New Developer Program and Security Key for FIDO2 and WebAuthn W3C Specifications |date=2018-04-10 |access-date=2018-05-11}}</ref> The first FIDO2-compatible authenticators with a display was Trezor Model T by SatoshiLabs, announced on 6 November 2019.<ref>{{cite web |url=https://medium.com/trezor-security-blog/make-passwords-a-thing-of-the-past-a402745750dc |title=Make Passwords a Thing of the Past, FIDO2 Is Now Available on Trezor Model T |date=2019-11-06 |access-date=2019-11-06}}</ref> Trezor Model T was also the first authenticator that allowed users to select which FIDO2 resident credential should be used directly on a device.
The first Security Level 2 certified FIDO2 key, called "Goldengate" was announced one year later by eWBM on 8 April 2019.<ref>{{cite press release |url=https://www.ewbm.com/press/pr2/ |title=eWBM: eWBM's Goldengate Fingerprint Reader is First to Get FIDO L2 Certification |date=2019-04-08 |access-date=2019-06-15}}</ref><ref>{{cite press release |url=https://mobileidworld.com/ewbm-goldengate-fingerprint-reader-fido-l2-certification-804084/ |title=Mobile ID World, Alex Perala: eWBM's Goldengate Fingerprint Reader is First to Get FIDO L2 Certification |date=2019-04-09 |access-date=2019-06-15}}</ref>
[[Dropbox]] announced support for WebAuthn logins (as a 2nd factor) on 8 May 2018.<ref>{{cite web |url=https://blogs.dropbox.com/tech/2018/05/introducing-webauthn-support-for-secure-dropbox-sign-in/ |title=Introducing WebAuthn support for secure Dropbox sign in |first=Brad |last=Girardeau |publisher=Dropbox |work=Dropbox Tech Blog |date=2018-05-08 |access-date=2018-05-11}}</ref>
[[Apple Inc.|Apple]] announced that [[Face ID]] or [[Touch ID]] could be used as a WebAuthn platform authenticator with [[Safari (web browser)|Safari]] on 24 June 2020.<ref>{{Cite web |date=2022-12-16 |title=Safari 14 Release Notes |url=https://developer.apple.com/documentation/safari-release-notes/safari-14-release-notes |access-date=2022-12-16 |website=Apple Developer Documentation}}</ref>
== API ==
WebAuthn implements an extension of the W3C's more general [[Credential Management]] [[application programming interface|API]], which is an attempt to formalize the interaction between [[website]]s and [[web browser]]s when exchanging user credentials. The Web Authentication API<ref>{{cite web |title=Web Authentication API |url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |publisher=[[Mozilla]] |access-date=16 March 2019}}</ref><ref>{{cite web |last1=Ackermann |first1=Yuriy |title=Introduction to WebAuthn API |url=https://medium.com/@herrjemand/introduction-to-webauthn-api-5fd1fb46c285 |publisher=Medium |access-date=8 March 2019 |date=15 January 2019}}</ref> extends the Credential Management <code>navigator.credentials.create()</code> and <code>navigator.credentials.get()</code> [[JavaScript]] methods so they accept a <code>publicKey</code> parameter. The <code>create()</code> method is used for registering public key [[authenticator]]s as part of associating them with user accounts (possibly at initial account creation time but more likely when adding a new security device to an existing account) while the <code>get()</code> method is used for authenticating (such as when logging in).
To check if a browser supports WebAuthn, scripts should check if the <code>window.PublicKeyCredential</code> interface is defined. In addition to <code>PublicKeyCredential</code>, the standard also defines the <code>AuthenticatorResponse</code>, <code>AuthenticatorAttestationResponse</code>, and <code>AuthenticatorAssertionResponse</code> interfaces in addition to a variety of dictionaries and other datatypes.
The API does not allow direct access to or manipulation of private keys, beyond requesting their initial creation.
== Reception ==
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:
* Through the mandated use of [[CBOR Object Signing and Encryption|COSE]] (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 not considered to be best practice among cryptographers any more.
* 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.
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.
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>
== See also ==
*[[FIDO Alliance]]
== References ==
{{reflist}}
== External links ==
*[https://www.w3.org/TR/webauthn/ Web Authentication: An API for accessing Public Key Credentials]
*[https://www.w3.org/Webauthn/ Web Authentication Working Group]
*[https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API on MDN]
*[https://github.com/herrjemand/awesome-webauthn WebAuthn Awesome]
{{Web interfaces}}
[[Category:Authentication methods]]
[[Category:Identification]]
[[Category:World Wide Web Consortium standards]]
[[Category:Internet security]]
[[Category:Web technology]]