Basic Authentication mechanism of HTTP

1. Authentication 1.1 HTTP Challenge/Response authentication Framework

HTTP provides a native challenge/response (Challenge/response) framework that simplifies the authentication process for users. The authentication model for HTTP is as follows:

When the WEB application receives an HTTP request message, the server does not perform the action as requested, but responds with a "certification challenge", asking the user to provide some confidential information to indicate who he is and thus to challenge it.

When the user initiates the request again, a confidential certificate (user name and password) is attached. If the certificate does not match, the server can challenge the client again, or produce an error message. If the certificate matches, the request can be completed as expected.

1.2 Authentication protocol and header

HTTP provides a scalable framework for different authentication protocols through a customizable set of control headers. The header format and content listed below will vary depending on the authentication protocol. The authentication protocol is also specified in the HTTP Authentication header.

HTTP defines two official authentication protocols: Basic authentication and Digest authentication.

4 Steps to Certification:

Steps	Header	Description	Method/Status
Request		The first request has no authentication information	GET
Question	Www-authenticate	The server rejected the request with 401 status, stating that the user is required to provide a user name and password. The server may be divided into different zones, each with its own password, so the server will describe the protected area at the Www-authenticate header. Similarly, the authentication algorithm is specified in the Www-authenticate header	401 Unauthorized
Authorized	Authorization	The client re-sends the request, but this time a Authorization header is appended to describe the authentication algorithm, user name, and password	GET
Success	Authentication-info	If the authorization certificate is correct, the server returns the document. Some authorization algorithms return some additional information related to the authorization session at the optional Authentication-info header	OK

As an example:

• When the server challenges a user, it returns a 401 unauthorized response and describes how and where to authenticate in the Www-authenticate header.
• When the client authorization server continues processing, the request is resent, but the encrypted password and some other authentication parameters are appended to the Authorization header.
• When the authorization request is completed successfully, the server returns a normal status code (such as a $ OK), and additional information may be appended to the Authentication-info header for the Advanced authentication algorithm.

1.3 Security Domain

How does HTTP allow the server to use different access rights for different resources? A realm directive is included in the Www-authenticate challenge. The WEB server organizes the protected documents into a secure domain (security realm). Each security domain can have a different set of authorized users.

For example, suppose the WEB server establishes two security domains: one for the company's financial information and the other for the personal home document. Different users have different access rights to each security domain. The company's CEO should be able to access sales forecasts, but should not allow him to access photos of employees and their families on vacation:

Here is an illusion of the Basic Authentication challenge, which specifies a domain:

HTTP/1.0 401 UnautiorizedWWW-Authenticate: Basic realm="Corporate Financials"

The domain should have a descriptive character name, such as Corporate Financials (company financial Information), to help users understand which user name and password to use. It is also helpful to list the server host name in the name of the security domain-for example, [email protected].

2. Basic Certification

In Basic authentication, the WEB server can deny a transaction, challenge the client, and ask the user to provide a valid user name and password. The server returns a 401 status code instead of a 200 status code to initialize the authentication challenge and specifies the security domain to access with the Www-authenticate response header. When the browser receives the challenge, a dialog box opens asking the user to enter the user name and password for the domain. Then the user name and password a little scrambling, and then with the Authorization request header back to the server.

HTTP Basic Authentication Packages The user name and password (separated by colons) and encodes it with Base-64 encoding.

2.1 Agent Certification

The intermediary proxy server can also implement the authentication function. Some organizations use a proxy server to authenticate users before they access a server, LAN, or wireless network. Access policies can be centrally managed on the proxy server, so providing unified access control over the resources within an organization through a proxy server is a convenient way. The first step in this process is to identify identities through proxy authentication (authentication).

The steps for agent authentication are the same as for Web server authentication. But the header and the status code are different.

Web Server	Proxy Server
Unauthorized Status code:401	Unauthorized Status code:407
Www-authenticate	Proxy-authenticate
Authorization	Proxy-authorization
Authentication-info	Proxy-authorization-info

3. Basic certification of security defects

Basic authentication can only be used to prevent unintended access by non-malicious users, or to use encryption techniques such as SSL.

Basic authentication has the following security flaws:

1. Basic authentication sends a user name and password over the network, both of which are represented in a form that is easily decoded. In fact, the password is transmitted in clear text and can be read and captured by anyone. Although Base-64 encoding hides usernames and passwords, it is unlikely that friendly users will inadvertently see the password while observing the network, but the BASE-64 encoded username and password can be easily decoded by the reverse encoding process, or even manually decoded in seconds by a paper pen. So the Base-64 encoded password is actually "plaintext" transmitted. If a motivated third-party user is likely to intercept the user name and password sent by the Basic authentication, it is necessary to send all HTTP transactions over the SSL encrypted channel, or use a more secure authentication protocol, such as Digest authentication.
2. Even if the password is encrypted in a more difficult way, a third-party user can still capture the modified user name and password and replay the modified user name and password once to the original server to gain access to the server. There are no measures that can be used to prevent these replay attacks.
3. Even if you use Basic authentication for less important applications, such as access control for your corporate intranet or access to personalized content, some bad habits can make it dangerous. Many users will use the same user name and password between these services because they cannot receive a large number of password-protected services. For example, a cunning villain would capture a clear-text user name and password from a free Internet mail site, and then find that the same user name and password could be used to access important online banking sites.
4. Basic authentication does not provide any protection against agents and intermediate nodes as intermediaries, they do not modify the authentication header, but modify the rest of the message, which seriously alters the nature of the transaction.
5. Fake servers can easily cheat on basic certifications. If the user is actually connected to a malicious server or gateway, allowing the user to believe that he is connecting to a legitimate host that is protected by Basic authentication, the attacker can request the user to enter a password, store it for future use, and then fabricate an error message to send to the user.

Basic Authentication mechanism of HTTP