Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how Webauthn can achieve password-free login in browsers. Many people may not know much about it. In order to make you understand better, the editor has summarized the following for you. I hope you can get something according to this article.

1. What is Webauthn?

WebAuthn (Web Authentication) is a Web standard issued by the World wide Web Consortium (W3C). WebAuthn is a core component of the FIDO2 project under the guidance of the FIDO Alliance. The goal of the project is to standardize the user's interface to public key authentication for Web-based applications and services.

WebAuthn full name Web Authentication API uses asymmetric (public-key) cryptography (asymmetric encryption) instead of password or SMS text to register, verify, second-factor authentication (two-factor verification) on the website. Solve phishing (phishing), data breaches (data corruption), SMS text attacks, other two-factor verification and other major security problems. It also significantly improves ease of use (because users do not have to manage many more and more complex passwords).

The biometric verification methods supported by WebAuthn include fingerprint and facial recognition of laptops and fingerprint recognition of Android devices. Users in pursuit of high security can also purchase additional FIDO-compatible physical security keys. Full FIDO support includes fingerprint recognition, facial recognition, iris recognition, voice recognition, physical keys (USB connection, Bluetooth connection, NFC connection), and supporting device systems include: Windows 10, Linux, Mac OS, Android, iOS, smartwatch, etc.

Support systems and browsers include:

Windows:Edge,Firefox,ChromeLinux: Firefox,ChromeMacOS: Safari,Firefox,ChromeAndroid:Firefox,ChromeiOS: Microsoft Edge on Brave,Firefox,ChromeWindows, using Chrome on Windows Hello (with facial recognition, fingerprint recognizer or PIN) MacOS using Chrome on Touch ID fingerprint recognizer Android, using fingerprint recognizer 2. Webauthn architecture implementation

WebAuthn replaces the password with a public key certificate to complete user registration and authentication (login). It is more like an enhancement or supplement to existing authentication. In order to ensure the security of communication data, it is generally based on HTTPS (TLS) communication. In this process, there are four modules.

Server (server):

It can be regarded as a relying party (Relying Party), which stores the user's public key and is responsible for the user's registration and authentication.

JavaScript (Js script):

Call the browser API to communicate with Server and initiate the registration or authentication process.

Browser (browser):

The Credential Management API containing WebAuthn is needed to provide js calls, and it is also necessary to communicate with the authentication module and uniformly encapsulate the interaction of hardware devices by the browser.

Authenticator (Authentication Module):

It can create, store and retrieve identity certificates. It is usually a hardware device (smart card, USB,NFC, etc.) and may have been integrated into your operating system (such as Windows Hello,MacOS 's Touch ID, etc.)

Registration proc

1) Application request registration

The application sends out the registration request, and the server provides api to initiate the registration request by the front-end js call.

2) the server returns registration data

The server sends the challenge code, user information, and relying party information back to the application.

Challenge: the challenge code must be a random buffer (at least 16 bytes) and must be generated on the server to ensure security.

User info: user information, the server needs to know who is going to register. In normal application scenarios, the first step is to obtain the current legitimate user information under other auxiliary authentication, such as the first step is to transmit a static user name and password to do a verification. The server recognizes that it is a legitimate user request to register.

Relying party info: server-side context, including the PublicKeyCredential of AuthenticatorAttestationResponse

3) the browser calls the authenticator

Request the authenticator to create the authentication certificate, and the browser generates client data (clientData) to generate clientDataHash (from the challenge code, the SHA-256 hash of the server context) to the authenticator.

4) the authenticator creates a key pair

The authenticator usually asks the user to confirm the ownership of the key in some form, such as entering PIN, using fingerprints, performing iris scanning, etc., to prove the user's presence and agree to register. After the authentication passes, the authenticator creates a new asymmetric key pair and securely stores the private key for future authentication. The public key will be part of the proof and will be signed by the private key burned in the authenticator during production. This private key will have a certificate chain that can be verified.

5) the authenticator data is returned to the browser

The returned data, including the new public key, globally unique credential ID, and authentication credential data (Attestation object l contains FIDO metadata) is returned to the browser.

6) the browser packages the data and sends it to the server

Contains the public key, globally unique credential ID, authentication credential data, client data (clientData); wherein the authentication credential data contains clientDataHash, which can be determined that the currently generated public key is allocated to the user currently requesting registration.

7) the server completes the registration

Upon receipt of a registration request from the client, the server needs to perform a series of checks to ensure that the registration is complete and that the data has not been tampered with. The steps include:

a. Verify that the challenge received is the same as the challenge sent b. Ensure that origin is in line with expectations c. Use the certificate chain of the corresponding verifier model to verify the signature and verification of the clientDataHash

A complete list of validation steps can be found in the WebAuthn specification. Once the authentication is successful, the server will associate the new public key with the user account for future use when the user wants to use the public key for authentication.

Certification process

1) Application requests authentication

The application sends out the registration request, and the server provides api to initiate the registration request by the front-end js call.

2) the server returns the challenge code

The challenge code must be a large buffer of random information, such as more than 100 bytes, and must be generated on the server to ensure the security of the authentication process.

3) the browser calls the authenticator

The browser generates client-side data (clientData) generates clientDataHash (by the challenge code, the SHA-256 hash of the server context) and transmits it to the authenticator.

4) authenticator creation assertion

The authenticator prompts the user to authenticate (such as entering PIN, using fingerprints, performing iris scanning, etc.) and creates assertions by signing the clientDataHash and authentication data with the private key saved at the time of registration.

5) the authenticator data is returned to the browser

Return authentication data and signature to the browser.

6) the browser packages the data and sends it to the server

Contains client data (clientData), authentication data, and signatures to the browser.

7) the server completes the registration

Upon receipt of an authentication request from the browser, the server needs to perform a series of checks to ensure that the authentication is complete and that the data has not been tampered with, including:

a. Verify the authenticator's signature using the public key stored during the enrollment request. b. Ensure that the challenge code signed by the authenticator matches the challenge code generated by the server. c. Check the account information to see if it is an existing account on the server side.

A complete list of steps for validating assertions can be found in the WebAuthn specification. Assuming the authentication is successful, the server will notice that the user is now authenticated. This is beyond the scope of the WebAuthn specification, but there is an option to delete a new cookie for the user session.

3. Application scenarios of Webauthn

Webauthn provides a secure password-free authentication standard, abandons the password completely, and the integration and management of security hardware devices and biometric identification are completed by the operating system. The browser calls the capabilities provided by the operating system to form the authenticator, and the application developer can complete the FIDO authentication according to the standard and browsing integration, without caring about the compatibility of hardware devices and biometric algorithms. It makes it easier and more secure for application developers to integrate FIDO authentication and discard passwords.

Scenario 1: integrated Windows hello authentication

The Windows hello module of Win10 system can integrate face, fingerprint, pin code and other authentication methods. When registering or authenticating web applications running on windows, the browser can directly integrate with windows hello to obtain user identity credentials for authentication.

Scenario 2: integrated MacOS Touch ID authentication

The MacBook system comes with TouchID integrated fingerprint authentication, and the browser can directly wake up the TouchID of mac for authentication through the interface. Web applications that support Webauthn can log in directly using TouchID.

Scenario 3: integrated Android fingerprint authentication

Due to the heterogeneity of Android system manufacturers, different mobile phone manufacturers will have different face recognition or fingerprint recognition modules, which are encapsulated and docked with biological devices at the system level through Webauthn, so that the application system does not need to care about the heterogeneous lines of the Android system and directly log in using the biological authentication of the mobile phone.

Scenario 4: integrated iOS face authentication

The iPhone system comes with Face ID integrated face authentication, and the browser can directly wake up Face ID for authentication through the interface. Web applications that support Webauthn can log in directly using Face ID.

Scenario 5: using YubiKey authentication

YubiKey is an external ukey to store the user's private key for webauthn authentication. It can be accessed through the usb interface in both pc and mobile app;pc mode, and through nfc in mobile app mode.

Shortcomings of 4.Webauthn

Webauthn relies on the browser to communicate with the authentication module, so you must use the latest browsing to support it. It is not easy to use without browser, such as CS application or mobile APP.

The goal of Webauthn design is to solve the problem of authentication. Once authenticated, users can access all resources. In the zero-trust architecture, the scenario of permanent use of one-time authentication cannot be allowed.

After reading the above, do you have any further understanding of how Webauthn implements password-free login in browsers? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.