This time, let’s dig a little deeper – HTTP digest authentication

This is the tenth article in the web series, with more to come. Stay tuned! Let’s ride the waves together!

preface

In the previous article, we looked at basic authentication in the HTTP authentication framework. It is based on a challenge/response model. In this article, we take a cursory look at another authentication protocol: digest authentication. Of course, summary authentication is not the most secure authentication method, and has not been widely used. But the concepts are worth learning. Enter the body below!

The improvement of certification

Authentication is another authentication protocol supported by HTTP, which tries to fix the defects of basic authentication. The improvements are as follows:

• Passwords are not sent in clear text.
• Prevents malicious users from capturing and replaying the authentication handshake process.
• You can selectively prevent packet content tampering.
• Defend against several other common attacks.

Protect passwords with digests

The recommendation for authentication is “never send a password over the network “. Instead of sending a password directly, the client will send a” fingerprint “or” digest “of the password (which is interpreted as something that has been encrypted and is not reversible). Compare the basic authentication process with the summary authentication process:

One-way the

The common way to generate digests is to use MD5, which is a one-way, irreversible process. It produces a fixed 128-bit output representing a summary of input information for uncertain inputs. Typically, 128-bit information is represented in 32-bit hexadecimal.

Use random numbers to prevent replay attacks

As you might imagine, a third party could get the digest to pass authentication by the server. So, “random numbers” are added to prevent this from happening. The server sends a random number to the client at challenge time, which the client needs to use to generate the digest. Of course, random numbers are variable, which can effectively prevent replay attacks.

The handshake mechanism of authentication

Abstract Authentication is an upgraded version of basic authentication, which uses the same header as basic authentication, but adds the authorization-info header. The server sends authentication related information to the client after the authentication is passed.

• After receiving the authentication request, the server generates a random number in (1) and passesWWW-AuthenticateSend the header to the client (2).
• In (3), the client selects the digest algorithm, which computes the digest from the password and other information. Passed in (4)AuthorizationThe header is sent to the server. If the client requires authentication from the server, you can send a random number to the client.
• (5), the server receives the digest, calculates its own digest, and verifies it. If the client performs digest authentication on the server, the server sends a digest of the calculation in (6), and the client can authenticate after receiving the data.

Calculation of abstracts

Now let’s understand how the summary is calculated

The input data of the algorithm

• The unidirectional hash function H(d) and the abstract KD(s,d), where S represents the password and D represents the data.
• A block of data that protects security information, including passwords, is called A1
• A data block that protects the non-secret attributes of the request message is called A2

A1 and A2 were processed with H and KD to produce summaries.

Algorithm H(D) and KD(s, D)

There are many authentication algorithms, but RFC 2617 recommends using MD5 and MD5-sess. If no algorithm is specified, MD5 is used by default. Details are as follows:

H(d) = MD5(d)
KD(s, d) = H(concatenate(s:d))
Copy the code

Safety related data A1

The generation of A1 is related to the algorithm. According to RFC 2617, there are the following rules:

• Composition of MD5 algorithm A1:

  A1 = <user>:<realm>:<password>
  Copy the code

• Composition of A1 of MD5-SESS algorithm:

  A1 = MD5(<user>:<realm>:<password>):<nonce>< cNone > Where, nonce indicates the current random number, and cNone indicates the client random numberCopy the code

Data related to the packet A2

A2 represents information related to the packet, such as URL, request method, and packet body. A2 helps prevent method, resource, or message tampering.

RFC 2617 states that A2 has two strategies based on the selected quality of protection (QOP) :

• whenqop="auth"Contains only the request method and URL.
• whenqop="auth-int", not only contains the request method and URL, but also adds the message body part.

The algorithm is summarized

Now that you know the elements necessary to compute the digest, let’s look at how the digest is ultimately computed. However, when calculating the final result, two situations arise: the request does not contain QOP (for compatibility with previous specifications), and the request contains QOP.

Nc is also the data sent by the client for verification.

Digest authentication session

When a client responds to a WWW-Authenticate challenge of the protected space, an authentication session is started for the protected space. The authentication session continues until the client receives another challenge to any of the servers in the protected space. Clients should remember authentication information for future use when building the Authorization head of a request in this protected space.

When authentication expires, the client can also use the information to build the request header without requiring the user to re-enter the account and password.

Pre authorization

In a normal authentication process, each request has a challenge session (see a in the figure below).

Ask questions
Authorization
The inquiry

Pre-authorization is not important for basic authentication (see here). After authenticating a site, the client can remember the user name and password with the user’s consent, and then send the user name and password the next time it authenticates the site.

For digest authentication, random numbers are used to prevent replay attacks. The random number of the server is arbitrary, and the client cannot generate the correct Authorization head before receiving the challenge.

For pre-authorization, there are three ways to generate random numbers. Once the client knows the random numbers, it can generate the correct Authorization head.

• The serverAuthentication-InfoThe header sends the next random number in advance.
• The server allows the same random number to be used for a short period of time.
• The server and client use synchronous, predictable random number generation algorithms.

Symmetric certification

Symmetric authentication means that the client can also authenticate the server after the server sends a challenge to the client. This requires the client to send the client random number. After the server calculates the abstract, it sends it to the client through the authorization-info header.

As we learned above, generating a summary requires A2(which is the relevant data related to the message) that contains the request method. There is no request method in the corresponding message. Therefore, there are differences in the determination of A2, as follows:

A few issues to pay attention to

Multiple inquiries

When the server does not know the specific capabilities of the client, it can issue both basic and summary authentication challenges to the client. When faced with multiple challenges, the client must respond with the strongest mechanism it supports.

Error handling

In digest authentication, if a client requests an instruction or its value incorrectly, or if an instruction is missing, the server should respond with 400 Bad Request.

If the request summary does not match, a login failure should be logged, a client fails multiple times in a row, and there may be an attacker guessing the password.

The server must ensure that the VALUE of the URL directive is the same as the value in the request line. The server should also respond with 400 Bad Requests.

To protect the space

You can use domains to divide server resources into different protected Spaces. Each protected space has its own authentication mechanism. The protected space determines the area where certificates can be automatically applied. For example, if a request is authorized, other requests of the protected space can also use the certificate in the following period of time. A single protected space cannot be extended to other areas without consideration.

Rewrite the URI

If the request goes through a proxy and the proxy overwrites the URI. This breaks digest authentication. Because digest authentication checks urIs.

conclusion

Okay, so that’s it for digest authentication. Some of the security risks of HTTP native authentication are not detailed. So if you’re interested, you can continue your research. As you can see from the study, HTTP was originally conceived in many ways, but it just didn’t meet the needs of The Times.

note

• Some pictures come from the network, if there is infringement, please inform.
• Please point out any mistakes. ‘!
• Your liking is the greatest compliment.