HTTP-Digest Authentication

Basic authentication is convenient and flexible, but extremely unsafe. The user name and password are transmitted in clear text, and no action is taken to prevent tampering with the message. The only way to safely use Basic authentication is to use it in conjunction with SSL.

Abstract authentication is another HTTP authentication protocol that is compatible with basic authentication, but is more secure. Abstract authentication attempts to fix a serious flaw in the Basic authentication protocol. Specifically, the summary certification has been modified as follows:

• Passwords will never be sent over the network in clear text mode.
• Prevents malicious users from capturing and replaying the certified handshake process.
• It is possible to selectively prevent tampering with the contents of the message.
• Guard against several other common ways of attacking.

Abstract authentication is not the safest protocol. Abstract authentication does not meet the many requirements of secure HTTP transactions. For these requirements, it is more appropriate to use the TLS and HTTPS protocols. However, abstract authentication is much more powerful than the basic authentication it is to replace.

How Digest Authentication Works

Here's how Digest authentication Works (simplified version):

A) The client has requested a protected document.

b) The server refuses to provide documentation until the client is able to prove that it knows the password to confirm its identity. The server initiates a challenge to the client asking for a password in the form of a user name and digest.

c) The client passes a digest of the password, proving that it knows the password. The server knows the secrets of all users, so the summary provided by the customer can be compared to the summary computed by the server itself to verify that the user knows the password. It is difficult for the other party to forge the correct digest without knowing the password.

d) The server compares the summary provided by the client to the summary computed within the server. If it matches, it means the client knows the password (or is lucky to guess!). ）。 You can set a digest function so that it produces many numbers, making it impossible to be lucky to guess a digest. After the server has matched the validation, the document is made available to the client-the entire process does not send a password on the network.

Replay attack

Using a digest eliminates the need to send passwords in clear text. You can send only a digest of the password, and you can be confident that no malicious user can easily decode the original password from the digest.

However, simply hiding the password does not avoid danger, because even if you do not know the password, the person with ulterior motives can intercept the digest and replay it to the server over and over again. The digest is as good as the password.

to prevent such replay attacks, the server can send a special token called a random number (nonce) to the client , which changes frequently (probably every millisecond, or every time the authentication is changed). The client appends this random number token to the password before calculating the digest.

Adding a random number to a password causes the digest to change with each change in the random number. The recorded password digest is valid only for a specific random number, and without a password, the attacker cannot calculate the correct digest, which prevents the replay attack from occurring.

Abstract authentication requires the use of random numbers, because this small replay weakness makes the non-randomized digest authentication as fragile as the basic authentication. The random number is transmitted from the server to the client in the Www-authenticate challenge.

Summary authentication Handshake mechanism

The following is a simplified summary authentication three-step handshake mechanism:

(1) The server calculates a random number.

(2) The server places this random number in the Www-authenticate Challenge message and sends it to the client with the list of algorithms supported by the server.

(3) The client chooses an algorithm to calculate the digest of the password and other data.

(4) The client sends a summary to the server in a Authorization message. If the client wants to authenticate the server, it can send the client random number.

(5) The server receives the digest, the selected algorithm, and the support data, and calculates the same digest as the client. The server then compares the locally generated digest with the digest sent over the network to verify that it matches. The client summary is created if the client in turn challenges the server with a random number of clients. The server can pre-calculate the next random number and pass it to the client in advance so that the next time the client can send the correct digest beforehand.

Pre-authorization

In a common authentication method, each request needs to have a request/challenge before the end of the transaction, see (a).

If the client knows in advance what the next random number is, it can cancel the request/Challenge loop so that the client can generate the correct Authorization header before the server makes a request. If the client can compute it before the server asks him to calculate the Authorization header, it can pre-send the Authorization header to the server without having to make a request/challenge. (b) shows the impact of this approach on performance.

Pre-authorization is not important (and very common) for basic certifications. Browsers typically maintain some client databases to store user names and passwords. Once a user authenticates with a site, the browser usually sends the correct AUTHORIZATION header for subsequent requests to that URL.

Because the Digest authentication uses the random number technique to destroy the replay attack, the pre-authorization is slightly more complicated for the Digest authentication. The server generates arbitrary random numbers, so it is not always possible to determine what Authorization header should be sent before the client receives the challenge.

Abstract authentication also provides a centralized pre-authorization method while retaining a lot of security features. Here are three alternative ways to get the correct random number by waiting for the client to wait for the new Www-authenticate challenge in these ways:

• The server pre-sends the next random number in the Authentication-info success header;
• The server allows the same random number to be used within a short period of time;
• The client and server use a synchronous, predictable random number algorithm.

Generate the next random number in advance

The next random number can be pre-supplied to the client in the Authentication-info success header. This header was sent with the last successful authentication of the "OK" response.

Authentication-info:nextnonce= "<nonce-value>"

With the next random number, the client can pre-publish the Authorization header.

Although this pre-authorization mechanism avoids the request/challenge loop (which speeds up transaction processing), it actually destroys the ability to pipe multiple requests to the same server, because it is important to receive the next random value before the next request is published. Pipelining is a fundamental technique to avoid delays. So this can cause a lot of performance damage.

Restricted random number reuse mechanism

Another method is not to pre-generate a sequence of random numbers, but to reuse the random number within a limited number of times. For example, the server might allow a random reuse 5 times, or reuse for 10 seconds.

In this case, the client is free to publish the request with the Authorization header, and because the random number is known beforehand, the request can also be piped. When the random number expires, the server sends the 401 unauthorized challenge to the client and sets the Www-authenticate:stale=true directive:

Www-authenticate:digest realm= "<realm-value>", nonce= "<nonce-value>", stale=true

Reusing random numbers makes it easier for attackers to successfully implement replay attacks. While this does reduce security, the lifetime of the reused random number is controllable (from strict prohibition of reuse to longer reuse), so you should be able to find a balance between security and performance.

Generate random numbers synchronously

You can also use a time-synchronized random number generation algorithm, where the client and server can generate the same sequence of random numbers that a third party cannot easily predict, based on the shared key.

HTTP-Digest Authentication