WebAuthn: Difference between revisions
No edit summary |
No edit summary |
||
| Line 52: | Line 52: | ||
== Background == | == Background == | ||
The combination of username and password has been the standard mechanism for users to prove to a website that they are a specific person since the dawn of web-based services.<ref>{{Cite book |last1=Bonneau|first1=Joseph|last2=Herley|first2=Cormac|last3=Oorschot|first3=Paul C. van|last4=Stajano|first4=Frank|chapter=The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes |date=2012|title=2012 IEEE Symposium on Security and Privacy|pages=553–567|doi=10.1109/SP.2012.44 |bibcode=2012sp...conf...46B |isbn=978-1-4673-1244-8 }}</ref> However, password-based authentication has been known to be flawed for many years, even decades, with most issues relating to poor practices on either the user side or the server side. Users routinely reuse passwords across services (which exposes them to [[credential stuffing]]),<ref>{{Cite book |last1=Wang|first1=Chun|last2=Jan|first2=Steve T.K.|last3=Hu|first3=Hang|last4=Bossart|first4=Douglas|last5=Wang|first5=Gang|title=Proceedings of the Eighth ACM Conference on Data and Application Security and Privacy |chapter=The Next Domino to Fall: Empirical Analysis of User Passwords across Online Services |date=2018-03-13 |language=en|publisher=ACM|pages=196–203|doi=10.1145/3176258.3176332|isbn=978-1-4503-5632-9}}</ref> choose weak passwords that can be brute-forced and predicted in a short amount of time<ref>{{Cite book |last1=Mazurek|first1=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|title=Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security - CCS '13 |chapter=Measuring password guessability for an entire university |date=2013 |language=en|publisher=ACM Press|pages=173–186|doi=10.1145/2508859.2516726|isbn=978-1-4503-2477-9}}</ref>, and store them in insecure 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> with each of those contributing to the likelihood of credentials and account compromise. Likewise, servers often deal with passwords improperly, both while storing them in [[Database|databases]], and while processing them. Common flaws include | The combination of username and password has been the standard mechanism for users to prove to a website that they are a specific person since the dawn of web-based services.<ref>{{Cite book |last1=Bonneau|first1=Joseph|last2=Herley|first2=Cormac|last3=Oorschot|first3=Paul C. van|last4=Stajano|first4=Frank|chapter=The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes |date=2012|title=2012 IEEE Symposium on Security and Privacy|pages=553–567|doi=10.1109/SP.2012.44 |bibcode=2012sp...conf...46B |isbn=978-1-4673-1244-8 }}</ref> However, password-based authentication has been known to be flawed for many years, even decades, with most issues relating to poor practices on either the user side or the server side. Users routinely reuse passwords across services (which exposes them to [[credential stuffing]]),<ref>{{Cite book |last1=Wang|first1=Chun|last2=Jan|first2=Steve T.K.|last3=Hu|first3=Hang|last4=Bossart|first4=Douglas|last5=Wang|first5=Gang|title=Proceedings of the Eighth ACM Conference on Data and Application Security and Privacy |chapter=The Next Domino to Fall: Empirical Analysis of User Passwords across Online Services |date=2018-03-13 |language=en|publisher=ACM|pages=196–203|doi=10.1145/3176258.3176332|isbn=978-1-4503-5632-9}}</ref> choose weak passwords that can be brute-forced and predicted in a short amount of time<ref>{{Cite book |last1=Mazurek|first1=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|title=Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security - CCS '13 |chapter=Measuring password guessability for an entire university |date=2013 |language=en|publisher=ACM Press|pages=173–186|doi=10.1145/2508859.2516726|isbn=978-1-4503-2477-9}}</ref>, and store them in insecure 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> with each of those contributing to the likelihood of credentials and account compromise. Likewise, servers often deal with passwords improperly, both while storing them in [[Database|databases]], and while processing them. Common flaws include plain-text storage, lack of [[Salt (cryptography)|salted]] [[Hash (cryptography)|hashing]] (or more advanced schemes for at-rest credentials),<ref>{{Cite web |title=Password Storage - OWASP Cheat Sheet Series |url=https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html |access-date=2026-11-01 |website=cheatsheetseries.owasp.org}}</ref> arbitrary restrictions on password length and [[charset]], mandatory ineffective password changes, and deliberate incompatibility with [[Password manager|password managers]] (for instance, by preventing passwords to be pasted).<ref>{{Cite journal |last=Lee |first=Kevin |last2=Sjöberg |first2=Sten |last3=Narayanan |first3=Arvind |date=2022 |title=Password policies of most top websites fail to follow best practices |url=https://www.usenix.org/conference/soups2022/presentation/lee |journal=SOUPS '22 |language=en |pages=561–580 |isbn=978-1-939133-30-4}}</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]]s) on the user. This standard was considered an 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 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 its 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 book |last1=Ghorbani Lyastani|first1=Sanam|last2=Schilling|first2=Michael|last3=Neumayr|first3=Michaela|last4=Backes|first4=Michael|last5=Bugiel|first5=Sven|title=2020 IEEE Symposium on Security and Privacy (SP) |chapter=Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless Authentication |date=May 2020 |publisher=IEEE|pages=268–285|doi=10.1109/SP40000.2020.00047|bibcode=2020sp...conf...24G |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" /> | 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]]s) on the user. This standard was considered an 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 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 its 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 book |last1=Ghorbani Lyastani|first1=Sanam|last2=Schilling|first2=Michael|last3=Neumayr|first3=Michaela|last4=Backes|first4=Michael|last5=Bugiel|first5=Sven|title=2020 IEEE Symposium on Security and Privacy (SP) |chapter=Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless Authentication |date=May 2020 |publisher=IEEE|pages=268–285|doi=10.1109/SP40000.2020.00047|bibcode=2020sp...conf...24G |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" /> | ||