Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Authenticator
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Examples== The following sections describe narrow classes of authenticators. For a more comprehensive classification, see the NIST Digital Identity Guidelines.<ref name="NIST-SP-800-63B">{{cite journal |last1=Grassi |first1=Paul A. |last2=Fenton |first2=James L. |last3=Newton |first3=Elaine M. |last4=Perlner |first4=Ray A. |last5=Regenscheid |first5=Andrew R. |last6=Burr |first6=William E. |last7=Richer |first7=Justin P. |title=NIST Special Publication 800-63B: Digital Identity Guidelines: Authentication and Lifecycle Management |url=https://pages.nist.gov/800-63-3/sp800-63b.html |publisher=[[National Institute of Standards and Technology]] (NIST) |access-date=5 February 2019 |doi=10.6028/NIST.SP.800-63b|year=2017 |doi-access=free }}</ref> ===Single-factor authenticators=== To use an authenticator, the claimant must explicitly indicate their intent to authenticate. For example, each of the following gestures is sufficient to establish intent: * The claimant types a password into a password field, or * The claimant places their finger on a fingerprint reader, or * The claimant presses a button to indicate approval The latter is called a test of user presence (TUP). To activate a single-factor authenticator (''something that one has''), the claimant may be required to perform a TUP, which avoids unintended operation of the authenticator. A [[password]] is a secret that is intended to be memorized by the claimant and shared with the verifier. Password authentication is the process whereby the claimant demonstrates knowledge of the password by transmitting it over the network to the verifier. If the transmitted password agrees with the previously shared secret, user authentication is successful. ====OATH OTP==== [[File:Aegis Authenticator 3.2 screenshot.png|thumb|upright=1.1|Example of one-time passwords]] One-time passwords (OTPs) have been used since the 1980s.{{citation needed|date=March 2019}} In 2004, an Open Authentication Reference Architecture for the secure generation of OTPs was announced at the annual [[RSA Conference]].<ref>{{cite web |last1=Kucan |first1=Berislav |title=Open Authentication Reference Architecture Announced |url=https://www.helpnetsecurity.com/2004/02/24/open-authentication-reference-architecture-announced/ |publisher=Help Net Security |access-date=26 March 2019 |date=24 February 2004}}</ref><ref>{{cite web |title=OATH Specifications and Technical Resources |url=https://openauthentication.org/specifications-technical-resources/ |publisher=[[Initiative for Open Authentication]] |access-date=26 March 2019}}</ref> The [[Initiative for Open Authentication]] (OATH) launched a year later.{{citation needed|date=March 2019}} Two IETF standards grew out of this work, the [[HMAC-based One-time Password algorithm|HMAC-based One-time Password (HOTP) algorithm]] and the [[Time-based One-time Password algorithm|Time-based One-time Password (TOTP) algorithm]] specified by RFC 4226 and RFC 6238, respectively. By OATH OTP, we mean either HOTP or TOTP. OATH certifies conformance with the HOTP and TOTP standards.<ref name="OATH-cert">{{cite web |title=OATH Certification |url=https://openauthentication.org/oath-certification/ |publisher=The [[Initiative for Open Authentication]] (OATH) |access-date=3 February 2019}}</ref> A traditional password (''something that one knows'') is often combined with a one-time password (''something that one has'') to provide two-factor authentication.<ref name="Hoffman-Andrews and Gebhart 2017">{{cite web |last1=Hoffman-Andrews |first1=Jacob |last2=Gebhart |first2=Gennie |title=A Guide to Common Types of Two-Factor Authentication on the Web |url=https://www.eff.org/deeplinks/2017/09/guide-common-types-two-factor-authentication-web |publisher=[[Electronic Frontier Foundation]] |access-date=26 March 2019 |date=22 September 2017}}</ref> Both the password and the OTP are transmitted over the network to the verifier. If the password agrees with the previously shared secret, and the verifier can confirm the value of the OTP, user authentication is successful. One-time passwords are generated on demand by a dedicated OATH OTP authenticator that encapsulates a secret that was previously shared with the verifier. Using the authenticator, the claimant generates an OTP using a cryptographic method. The verifier also generates an OTP using the same cryptographic method. If the two OTP values match, the verifier can conclude that the claimant possesses the shared secret. A well-known example of an OATH authenticator is [[Google Authenticator]],<ref name="Google-Authenticator">{{cite web |title=Google Authenticator |website=[[GitHub]] |url=https://github.com/google/google-authenticator/wiki |access-date=3 February 2019}}</ref> a phone-based authenticator that implements both HOTP and TOTP. ====Mobile Push==== A mobile push authenticator is essentially a native app running on the claimant's mobile phone. The app uses public-key cryptography to respond to push notifications. In other words, a mobile push authenticator is a single-factor cryptographic software authenticator. A mobile push authenticator (''something that one has'') is usually combined with a password (''something that one knows'') to provide two-factor authentication. Unlike one-time passwords, mobile push does not require a shared secret beyond the password. After the claimant authenticates with a password, the verifier makes an out-of-band authentication request to a trusted third party that manages a public-key infrastructure on behalf of the verifier. The trusted third party sends a push notification to the claimant's mobile phone. The claimant demonstrates possession and control of the authenticator by pressing a button in the user interface, after which the authenticator responds with a digitally signed assertion. The trusted third party verifies the signature on the assertion and returns an authentication response to the verifier. The proprietary mobile push authentication protocol runs on an out-of-band secondary channel, which provides flexible deployment options. Since the protocol requires an open network path to the claimant's mobile phone, if no such path is available (due to network issues, e.g.), the authentication process can not proceed.<ref name="Hoffman-Andrews and Gebhart 2017" /> ====FIDO U2F==== A [[FIDO Alliance|FIDO]] [[Universal 2nd Factor]] (U2F) authenticator (''something that one has'') is a single-factor cryptographic authenticator that is intended to be used in conjunction with an ordinary web password. Since the authenticator relies on public-key cryptography, U2F does not require an additional shared secret beyond the password. To access a U2F authenticator, the claimant is required to perform a test of user presence (TUP), which helps prevent unauthorized access to the authenticator's functionality. In practice, a TUP consists of a simple button push. A U2F authenticator interoperates with a conforming web [[user agent]] that implements the U2F JavaScript API.<ref>{{cite web |editor-last1=Balfanz |editor-first1=Dirk |editor-last2=Birgisson |editor-first2=Arnar |editor-last3=Lang |editor-first3=Juan |title=FIDO U2F JavaScript API |url=https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-javascript-api-v1.2-ps-20170411.html |publisher=[[FIDO Alliance]] |access-date=22 March 2019 |date=11 April 2017}}</ref> A U2F authenticator necessarily implements the CTAP1/U2F protocol, one of the two protocols specified in the FIDO [[Client to Authenticator Protocol]].<ref name="FIDO-CTAP">{{cite web |editor-last1=Brand |editor-first1=Christiaan |editor-last2=Czeskis |editor-first2=Alexei |editor-last3=Ehrensvärd |editor-first3=Jakob |editor-last4=Jones |editor-first4=Michael B. |editor-last5=Kumar |editor-first5=Akshay |editor-last6=Lindemann |editor-first6=Rolf |editor-last7=Powers |editor-first7=Adam |editor-last8=Verrept |editor-first8=Johan |title=Client to Authenticator Protocol (CTAP) |url=https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html |publisher=[[FIDO Alliance]] |access-date=22 March 2019 |date=30 January 2019}}</ref> Unlike mobile push authentication, the U2F authentication protocol runs entirely on the front channel. Two round trips are required. The first round trip is ordinary password authentication. After the claimant authenticates with a password, the verifier sends a challenge to a conforming browser, which communicates with the U2F authenticator via a custom JavaScript API. After the claimant performs the TUP, the authenticator signs the challenge and returns the signed assertion to the verifier via the browser. ===Multi-factor authenticators=== To use a multi-factor authenticator, the claimant performs full user verification. The multi-factor authenticator (''something that one has'') is activated by a [[Personal identification number|PIN]] (''something that one knows''), or a [[Biometrics|biometric]] (''something that is unique to oneself"; e.g. fingerprint, face or voice recognition''), or some other verification technique.<ref name="NIST-SP-800-63-3" /> , ====ATM card==== To withdraw cash from an [[automated teller machine]] (ATM), a bank customer inserts an ATM card into a cash machine and types a Personal Identification Number (PIN). The input PIN is compared to the PIN stored on the card's chip. If the two match, the ATM withdrawal can proceed. Note that an ATM withdrawal involves a memorized secret (i.e., a PIN) but the true value of the secret is not known to the ATM in advance. The machine blindly passes the input PIN to the card, which compares the customer's input to the secret PIN stored on the card's chip. If the two match, the card reports success to the ATM and the transaction continues. An ATM card is an example of a multi-factor authenticator. The card itself is ''something that one has'' while the PIN stored on the card's chip is presumably ''something that one knows''. Presenting the card to the ATM and demonstrating knowledge of the PIN is a kind of multi-factor authentication. ====Secure Shell==== [[Secure Shell]] (SSH) is a client-server protocol that uses public-key cryptography to create a secure channel over the network. In contrast to a traditional password, an SSH key is a cryptographic authenticator. The primary authenticator secret is the SSH private key, which is used by the client to digitally sign a message. The corresponding public key is used by the server to verify the message signature, which confirms that the claimant has possession and control of the private key. To avoid theft, the SSH private key (''something that one has'') may be encrypted using a [[passphrase]] (''something that one knows''). To initiate a two-factor authentication process, the claimant supplies the passphrase to the client system. Like a password, the SSH passphrase is a memorized secret but that is where the similarity ends. Whereas a password is a shared secret that is transmitted over the network, the SSH passphrase is not shared, and moreover, use of the passphrase is strictly confined to the client system. Authentication via SSH is an example of [[passwordless authentication]] since it avoids the transmission of a shared secret over the network. In fact, SSH authentication does not require a shared secret at all. ====FIDO2==== [[File:Bitwarden Passkey window screenshot.png|thumb|upright=1.2|Example of WebAuthn ([[Pixiv]] with [[Bitwarden]])]] The FIDO U2F protocol standard became the starting point for the [[FIDO2 Project]], a joint effort between the World Wide Web Consortium (W3C) and the FIDO Alliance. Project deliverables include the W3C Web Authentication ([[WebAuthn]]) standard and the FIDO [[Client to Authenticator Protocol]] (CTAP).<ref name="FIDO-FIDO2">{{cite web |title=FIDO2: Moving the World Beyond Passwords |url=https://fidoalliance.org/fido2/ |publisher=FIDO Alliance |access-date=30 January 2019}}</ref> Together WebAuthn and CTAP provide a strong authentication solution for the web. A FIDO2 authenticator, also called a WebAuthn authenticator, uses public-key cryptography to interoperate with a WebAuthn client, that is, a conforming web [[user agent]] that implements the WebAuthn [[JavaScript]] API.<ref name="W3C-WebAuthn">{{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 |url=https://www.w3.org/TR/webauthn/ |publisher=World Wide Web Consortium (W3C) |access-date=30 January 2019}}</ref> The authenticator may be a platform authenticator, a roaming authenticator, or some combination of the two. For example, a FIDO2 authenticator that implements the CTAP2 protocol<ref name="FIDO-CTAP" /> is a roaming authenticator that communicates with a WebAuthn client via one or more of the following transport options: [[USB]], [[near-field communication]] (NFC), or [[Bluetooth Low Energy]] (BLE). Concrete examples of FIDO2 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=November 20, 2018}}</ref> and the [[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=February 25, 2019}}</ref> A FIDO2 authenticator may be used in either single-factor mode or multi-factor mode. In single-factor mode, the authenticator is activated by a simple test of user presence (e.g., a button push). In multi-factor mode, the authenticator (''something that one has'') is activated by either a [[Personal identification number|PIN]] (''something that one knows'') or a [[Biometrics|biometric]] ("something that is unique to oneself").
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)