WebAuthn: Difference between revisions

m grammar and punctuation
m →top: grammar
Line 3: Line 3:
WebAuthn can be used in a single-factor capacity, whereby the user does not have to provide any additional information, such as username and passwords. However, for additional security, the party asking for authentication can still require those characteristics, effectively making this a [[multi-factor authentication]] scheme. Optionally, this can also be combined with other authentication factors, such as gestures or [[biometric]] verification, which improves overall security, while it is still unnecessary for users to type in long, complex strings of characters.
WebAuthn can be used in a single-factor capacity, whereby the user does not have to provide any additional information, such as username and passwords. However, for additional security, the party asking for authentication can still require those characteristics, effectively making this a [[multi-factor authentication]] scheme. Optionally, this can also be combined with other authentication factors, such as gestures or [[biometric]] verification, which improves overall security, while it is still unnecessary for users to type in long, complex strings of characters.


WebAuthn can be implemented in a variety of different ways, since the underlying cryptographic operations are performed by an "authenticator", which is an abstract functional model that is mostly agnostic on the details of how the key material is managed. This makes it possible to implement WebAuthn purely in software, but also to make use of a processor's [[trusted execution environment]] or a [[Trusted Platform Module]] (TPM). Sensitive cryptographic operations can also be offloaded to external hardware tokens that can in return be accessed via [[USB]], [[Bluetooth Low Energy]], or [[near-field communication]]s (NFC). This, in general, is more secure, as private key material is at no time accessible to software running on the host machine. The communication with external hardware tokens is designed to work with the [[Client-to-Authenticator Protocol]] (CTAP), making WebAuthn mostly backward compatible with the [[Universal 2nd Factor]] (U2F) standard.
WebAuthn can be implemented in a variety of different ways, since the underlying cryptographic operations are performed by an "authenticator", which is an abstract functional model that is mostly agnostic on the details of how the key material is managed. This makes it possible to implement WebAuthn purely in software, but also to make use of a processor's [[trusted execution environment]] or a [[Trusted Platform Module]] (TPM). Sensitive cryptographic operations can also be offloaded to external hardware tokens that can in turn be accessed via [[USB]], [[Bluetooth Low Energy]], or [[near-field communication]]s (NFC). This, in general, is more secure, as private key material is at no time accessible to software running on the host machine. The communication with external hardware tokens is designed to work with the [[Client-to-Authenticator Protocol]] (CTAP), making WebAuthn mostly backward compatible with the [[Universal 2nd Factor]] (U2F) standard.


WebAuthn as well as CTAP are both outgrowths of the FIDO2 project<ref name="fido2"/>, which  tries to standardize on secure and password-less authentication schemes and goes beyond the scope of browsers and the Web. It is based upon previous work done by the FIDO Alliance, in particular the [[Universal Authentication Framework]] (UAF) and Universal 2nd Factor (U2F) standards.
WebAuthn as well as CTAP are both outgrowths of the FIDO2 project<ref name="fido2"/>, which  tries to standardize on secure and password-less authentication schemes and goes beyond the scope of browsers and the Web. It is based upon previous work done by the FIDO Alliance, in particular the [[Universal Authentication Framework]] (UAF) and Universal 2nd Factor (U2F) standards.