IdeaWazaWiki

WebAuthn: Difference between revisions

← Older editNewer edit →

wikipedia>Sohom Datta

m move passkey info to passkey
fix
Line 52: Line 52:


== Background ==
== Background ==
Using a username and password has been the standard mechanism for users to prove to a website that they are a specific person.<ref>{{Cite journal |last=Bonneau|first=Joseph|last2=Herley|first2=Cormac|last3=Oorschot|first3=Paul C. van|last4=Stajano|first4=Frank|date=2012|title=The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes|url=https://ieeexplore.ieee.org/document/6234436|journal=2012 IEEE Symposium on Security and Privacy|pages=553–567|doi=10.1109/SP.2012.44}}</ref> However, this methods was known to be flawed. Users often reuse passwords across services<ref>{{Cite journal |last=Wang|first=Chun|last2=Jan|first2=Steve T.K.|last3=Hu|first3=Hang|last4=Bossart|first4=Douglas|last5=Wang|first5=Gang|date=2018-03-13|title=The Next Domino to Fall: Empirical Analysis of User Passwords across Online Services|url=https://dl.acm.org/doi/10.1145/3176258.3176332|journal=CODASPY '18|language=en|publisher=ACM|pages=196–203|doi=10.1145/3176258.3176332|isbn=978-1-4503-5632-9}}</ref>, use weak passwords that can be brute-forced, predicted<ref>{{Cite journal |last=Mazurek|first=Michelle L.|last2=Komanduri|first2=Saranga|last3=Vidas|first3=Timothy|last4=Bauer|first4=Lujo|last5=Christin|first5=Nicolas|last6=Cranor|first6=Lorrie Faith|last7=Kelley|first7=Patrick Gage|last8=Shay|first8=Richard|last9=Ur|first9=Blase|date=2013|title=Measuring password guessability for an entire university|url=http://dl.acm.org/citation.cfm?doid=2508859.2516726|journal=ACM CCS|language=en|publisher=ACM Press|pages=173–186|doi=10.1145/2508859.2516726|isbn=978-1-4503-2477-9}}</ref> or store them in ways that allows for their disclosure (for example writing them down on a piece of paper or a document).<ref>{{Cite conference|publisher=USENIX Association|isbn=978-1-939133-10-6|pages=13–30|last1=Habib|first1=Hana|last2=Naeini|first2=Pardis Emami|last3=Devlin|first3=Summer|last4=Oates|first4=Maggie|last5=Swoopes|first5=Chelse|last6=Bauer|first6=Lujo|last7=Christin|first7=Nicolas|last8=Cranor|first8=Lorrie Faith|title=User behaviors and attitudes under password expiration policies|location=Baltimore, MD|date=2018|conference=Fourteenth Symposium On Usable Privacy and Security (SOUPS 2018)|book-title=}}</ref>


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 |archive-date=19 February 2024 |archive-url=https://web.archive.org/web/20240219035634/https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html |url-status=live }}</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|archive-date=4 December 2020|archive-url=https://web.archive.org/web/20201204162752/https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-registry-v2.0-rd-20180702.html#user-verification-methods|url-status=live}}</ref>
As a result, in 2012, [[Google]] alongside [[Yubico]] started working on a standard called [[Universal 2nd Factor|Universal 2 Factor]] (U2F)<ref>{{Cite web |title=Yubico Company Timeline|url=https://www.yubico.com/why-yubico/yubico-innovation-history/|access-date=2026-06-04|website=Yubico|language=en-US}}</ref> that would allow websites to programatically verify a second-factor about the user by verifying the presence of hardware-based tokens (like [[Smart card|smart cards]]) on the user. This standard was considered a improvement over existing solutions like time-based one-time password ([[TOTP - Time-based One-time Password Algorithm|TOTP]]) or SMS-based authentication that still left the user vulnerable to sophisticated [[phishing]] campaigns. The standard was later adopted into a larger industry wide collaboration called the [[FIDO Alliance|FIDO (Fast IDentity Online) Alliance]]. The first draft for this proposed standard was published in 2014.<ref>{{Cite web |date=2014-12-09|title=FIDO Alliance Publishes Final FIDO 1.0 Specifications, First Industry Standards for Universal Strong Authentication|url=https://www.yubico.com/press-releases/fido-alliance-publishes-final-fido-1-0-specifications-first-industry-standards-for-universal-strong-authentication/|access-date=2026-06-04|website=Yubico|language=en-US}}</ref> In 2015, the FIDO Alliance started started developing the [[FIDO2 Project|FIDO 2 Project]], releasing a proposed standard where they sought to improve upon the existing U2F standard by addressing many of it's weaknesses.<ref>{{Cite web |date=2015-09-04|title=FIDO Complete Spec 2015-09-04|url=https://fidoalliance.org/specs/fido-v2.0-ps-20150904/FIDO-COMPLETE-v2.0-ps-20150904.pdf|access-date=5 June 2026|website=Fido Alliance}}</ref> For example, the U2F standard still required to use of passwords alongside a second factor which still left websites vulnerable to password leaks and other similar attacks that were common against passwords.<ref name=":0">{{Cite journal |last=Ghorbani Lyastani|first=Sanam|last2=Schilling|first2=Michael|last3=Neumayr|first3=Michaela|last4=Backes|first4=Michael|last5=Bugiel|first5=Sven|date=May 2020|title=Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless Authentication|url=https://ieeexplore.ieee.org/document/9152694/|journal=2020 IEEE S&P|publisher=IEEE|pages=268–285|doi=10.1109/SP40000.2020.00047|isbn=978-1-7281-3497-0}}</ref> Additionally, the U2F specification only verified the second factor device and did not perform any user authentication.<ref name=":0" /> This meant that if the second factor device had been stolen or lost anyone with access to the U2F device would be able to bypass the second factor of authentication for accounts linked to the device.<ref name=":0" />


* ''something you know:'' a secret such as a [[Personal identification number|PIN]], [[Password|passcode]] or swipe pattern
In November 2015, the FIDO Alliance submitted the first version of FIDO 2 to the World Wide Web Consortium as a proposed web standard.<ref>{{Cite web |date=2015-11-20|title=W3C Welcomes the FIDO 2.0 Member Submission|url=https://www.w3.org/blog/2015/w3c-fido/|access-date=2026-06-05|website=W3C|language=en}}</ref> In 2016, the W3C established a seperate [[Web Authentication Working Group|W3C Web Authentication Working Group]] to help write a standard for the new FIDO 2 project's authentication framework such that it could be integrated into browsers by default.<ref>{{Cite web |title=Web Authentication Working Group Charter|url=https://www.w3.org/2015/12/web-authentication-charter.html|access-date=2026-06-04|website=www.w3.org}}</ref> The standard was adopted by major browser vendors in late 2018 and early 2019, with Chrome supporting the standard in version 67, Firefox in version 60 and Safari in version 13.<ref>{{Cite web |date=2026-02-19|title=Web Authentication API - Web APIs {{!}} MDN|url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API|access-date=2026-06-04|website=MDN Web Docs|language=en-US}}</ref> In 2019, the FIDO 2 project alonside the W3C Web Authentication Working Group released the first version of the WebAuthn specification based on the FIDO 2 project as a W3C recommendation. Subsequently the standard has gone through two revisions, being called Level 1, Level 2 with a Level 3 revision still being considered a Candidate Recommendation {{As of|2026|June|lc=y}}<ref>{{Cite web |title=Web Authentication: An API for accessing Public Key Credentials - Level 3|url=https://www.w3.org/TR/webauthn-3/Overview.html|access-date=2026-06-04|website=www.w3.org}}</ref>, meaning that it is considered mature and feature complete and is ready for implementation and testing by interested parties.<ref>{{Cite web |title=W3C Process Document|url=https://www.w3.org/policies/process/20250818/Overview.html|access-date=2026-06-04|website=www.w3.org}}</ref>
* ''something you are:'' a [[Biometrics|biometric]] such as fingerprint, [[Facial recognition system|face]], 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|archive-date=7 June 2017|archive-url=https://web.archive.org/web/20170607122711/https://www.w3.org/TR/webauthn/Overview.html#user-verification|url-status=live}}</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 provides convenient access to user's smartphone, but occasionally fingerprint access fails, in which case user can use a PIN.
 
== Reasons for its design and standardization ==
 
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:
** 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.


== Passkey branding ==
== Passkey branding ==
Retrieved from "https://ideawaza.com/wiki/WebAuthn"