Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials, such as username or password, with a user's web browser. This can be used to confirm the identity of a user before sending sensitive information, such as online banking transaction history. It applies a hash function to the username and password before sending them over the network. In contrast, basic access authentication uses the easily reversible Base64 encoding instead of hashing, making it non-secure unless used in conjunction with TLS.

Technically, digest authentication is an application of cryptographic hashing with usage of nonce values to prevent replay attacks. It uses the HTTP protocol.

DIGEST-MD5 as a SASL mechanism specified by is obsolete since July 2011.Moving DIGEST-MD5 to Historic, July 2011.

Overview

Digest access authentication was originally specified by (An Extension to HTTP: Digest Access Authentication). RFC 2069 specifies roughly a traditional digest authentication scheme with security maintained by a server-generated nonce value. The authentication response is formed as follows (where HA1 and HA2 are names of string variables, method is the HTTP method verb, and digestURI the URI to be accessed):

HA1 = MD5(username:realm:password) HA2 = MD5(method:digestURI) response = MD5(HA1:nonce:HA2)

An MD5 hash is a 16-byte value. The HA1 and HA2 values used in the computation of the response are the hexadecimal representation (in lowercase) of the MD5 hashes respectively.

RFC 2069 was later replaced by (HTTP Authentication: Basic and Digest Access Authentication). RFC 2617 introduced a number of optional security enhancements to digest authentication; "quality of protection" (qop), nonce counter incremented by client, and a client-generated random nonce. These enhancements are designed to protect against, for example, chosen-plaintext attack cryptanalysis.

If the algorithm directive's value is "MD5" or unspecified, then HA1 is

HA1 = MD5(username:realm:password)

If the algorithm directive's value is "MD5-sess", then HA1 is

HA1 = MD5(MD5(username:realm:password):nonce:cnonce)

If the qop directive's value is "auth" or is unspecified, then HA2 is

HA2 = MD5(method:digestURI)

If the qop directive's value is "auth-int", then HA2 is

HA2 = MD5(method:digestURI:MD5(entityBody))

If the qop directive's value is "auth" or "auth-int", then compute the response as follows:

response = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2)

If the qop directive is unspecified, then compute the response as follows:

response = MD5(HA1:nonce:HA2)

The above shows that when qop is not specified, the simpler RFC 2069 standard is followed.

In September 2015, RFC 7616 replaced RFC 2617 by adding 4 new algorithms: "SHA-256", "SHA-256-sess", "SHA-512-256" and "SHA-512-256-sess". The encoding is equivalent to "MD5" and "MD5-sess" algorithms, with MD5 hashing function replaced with SHA-256 and SHA-512-256.

In , Firefox 93 implemented the "SHA-256" and "SHA-256-sess" algorithms for digest authentication. However, support for "SHA-512-256", "SHA-512-256-sess" algorithms and username hashing is still lacking.

In , Chromium 117 implemented "SHA-256" and "SHA-256-sess".

Impact of MD5 security on digest authentication

The MD5 calculations used in HTTP digest authentication is intended to be "one way", meaning that it should be difficult to determine the original input when only the output is known. If the password itself is too simple, however, then it may be possible to test all possible inputs and find a matching output (a brute-force attack) – perhaps aided by a dictionary or suitable look-up list, which for MD5 is readily available.List of rainbow tables, Project Rainbowcrack. Includes multiple MD5 rainbow tables.

The HTTP scheme was designed by Phillip Hallam-Baker at CERN in 1993 and does not incorporate subsequent improvements in authentication systems, such as the development of keyed-hash message authentication code (HMAC). Although the cryptographic construction that is used is based on the MD5 hash function, collision attacks were in 2004 generally believed to not affect applications where the plaintext (i.e. password) is not known. However, claims in 2006 cause some doubt over other MD5 applications as well.

HTTP digest authentication considerations

Advantages

HTTP digest authentication is designed to be more secure than traditional digest authentication schemes, for example "significantly stronger than (e.g.) CRAM-MD5 ..." (RFC 2617).Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., & Stewart, L. (1999). HTTP Authentication: Basic and Digest Access Authentication (RFC Internet Official Protocol Standards No. 2617). Internet Engineering Task Force. https://www.rfc-editor.org/info/rfc2617/

Some of the security strengths of HTTP digest authentication are:

The password is not sent clear to the server. The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss) to store HA1 rather than the cleartext password (however, see disadvantages of this approach) Client nonce was introduced in RFC 2617, which allows the client to prevent chosen-plaintext attacks, such as rainbow tables that could otherwise threaten digest authentication schemes Server nonce is allowed to contain timestamps. Therefore, the server may inspect nonce attributes submitted by clients, to prevent replay attacks Server is also allowed to maintain a list of recently issued or used server nonce values to prevent reuse It prevents Phishing because the plain password is never sent to any server, be it the correct server or not. (Public key systems rely on the user being able to verify that the URL is correct.)

Disadvantages

There are several drawbacks with digest access authentication: The website has no control over the user interface presented to the end user. Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode Digest access authentication is vulnerable to a man-in-the-middle (MITM) attack. For example, a MITM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode. To extend this further, digest access authentication provides no mechanism for clients to verify the server's identity A server can store HA1 = MD5(username:realm:password) instead of the password itself. However, if the stored HA1 is leaked, an attacker can generate valid responses and access documents in the realm just as easily as if they had access to the password itself. The table of HA1 values must therefore be protected as securely as a file containing plaintext passwords. Digest access authentication prevents the use of a strong password hash (such as bcrypt) when storing passwords (since either the password, or the digested username, realm and password must be recoverable)

Also, since the MD5 algorithm is not allowed in FIPS, HTTP Digest authentication will not work with FIPS-certifiedThe following is a list of FIPS approved algorithms: crypto modules.

Alternative authentication protocols

By far the most common approach is to use a HTTP+HTML form-based authentication cleartext protocol, or more rarely Basic access authentication. These weak cleartext protocols used together with HTTPS network encryption resolve many of the threats that digest access authentication is designed to prevent. However, this use of HTTPS relies upon the end user to accurately validate that they are accessing the correct URL each time to prevent sending their password to an untrusted server, which results in phishing attacks. Users often fail to do this, which is why phishing has become the most common form of security breach.

Some strong authentication protocols for web-based applications that are occasionally used include:

Public key authentication (usually implemented with a HTTPS / SSL client certificate) using a client certificate. Kerberos or SPNEGO authentication, employed for example by Microsoft IIS running configured for Integrated Windows Authentication (IWA). Secure Remote Password protocol (preferably within the HTTPS / TLS layer). However, this is not implemented by any mainstream browsers. JSON Web Token (JWT) is a JSON-based standard RFC 7519 for creating access tokens that assert some number of claims.

Example with explanation

The following example was originally given in RFC 2617 and is expanded here to show the full text expected for each request and response. Note that only the "auth" (authentication) quality of protection code is covered – , only the Opera and Konqueror web browsers are known to support "auth-int" (authentication with integrity protection). Although the specification mentions HTTP version 1.1, the scheme can be successfully added to a version 1.0 server, as shown here.

This typical transaction consists of the following steps:

The client asks for a page that requires authentication but does not provide a username and password.A client may already have the required username and password without needing to prompt the user, e.g. if they have previously been stored by a web browser. Typically this is because the user simply entered the address or followed a link to the page. The server responds with the 401 "Unauthorized" response code, providing the authentication realm and a randomly generated, single-use value called a nonce. At this point, the browser will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a username and password. The user may decide to cancel at this point. Once a username and password have been supplied, the client re-sends the same request but adds an authentication header that includes the response code. In this example, the server accepts the authentication and the page is returned. If the username is invalid and/or the password is incorrect, the server might return the "401" response code and the client would prompt the user again.

Client request (no authentication) GET /dir/index.html HTTP/1.0 Host: localhost (followed by a new line, in the form of a carriage return followed by a line feed).

Server response HTTP/1.0 401 Unauthorized Server: HTTPd/0.9 Date: Sun, 10 Apr 2014 20:26:47 GMT WWW-Authenticate: Digest realm="[email protected]", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: text/html Content-Length: 153

<!DOCTYPE html> <html> <head> <meta charset="UTF-8" /> <title>Error</title> </head> <body> <h1>401 Unauthorized.</h1> </body> </html> Client request (username "Mufasa", password "Circle Of Life") GET /dir/index.html HTTP/1.0 Host: localhost Authorization: Digest username="Mufasa", realm="[email protected]", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" (followed by a blank line, as before).

Server response HTTP/1.0 200 OK Server: HTTPd/0.9 Date: Sun, 10 Apr 2005 20:27:03 GMT Content-Type: text/html Content-Length: 7984 (followed by a blank line and HTML text of the restricted page).

The "response" value is calculated in three steps, as follows. Where values are combined, they are delimited by colons.

The MD5 hash of the combined username, authentication realm and password is calculated. The result is referred to as HA1. The MD5 hash of the combined method and digest URI is calculated, e.g. of "GET" and "/dir/index.html". The result is referred to as HA2.