Digest access authentication


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 MD5 cryptographic hashing with usage of nonce values to prevent replay attacks. It uses the HTTP protocol.

Overview

Digest access authentication was originally specified by RFC 2069. 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 :
HA1 = MD5
HA2 = MD5
response = MD5

A MD5 hash is a 16-byte value. The HA1 and HA2 values used in the computation of the response are the hexadecimal representation of the MD5 hashes respectively.
RFC 2069 was later replaced by RFC 2617. RFC 2617 introduced a number of optional security enhancements to digest authentication; "quality of protection" , 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

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

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

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

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

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

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" and "SHA-512-sess". The encoding is equivalent to "MD5" and "MD5-sess" algorithms, with MD5 hashing function replaced with SHA-256 and SHA-512.

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 – perhaps aided by a dictionary or suitable look-up list, which for MD5 is readily available.
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. 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 is not known. However, claims in 2006 cause some doubt over other MD5 applications as well. So far, however, MD5 collision attacks have not been shown to pose a threat to digest authentication, and the RFC 2617 allows servers to implement mechanisms to detect some collision and replay attacks.

HTTP digest authentication considerations

Advantages

HTTP digest authentication is designed to be more secure than traditional digest authentication schemes, for example "significantly stronger than CRAM-MD5...".
Some of the security strengths of HTTP digest authentication are:
There are several drawbacks with digest access authentication:
Also, since the MD5 algorithm is not allowed in FIPS, HTTP Digest authentication will not work with FIPS-certified 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:
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" quality of protection code is covered – as of 2005, only the Opera and Konqueror web browsers are known to support "auth-int". 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:
  1. The client asks for a page that requires authentication but does not provide a username and password. Typically this is because the user simply entered the address or followed a link to the page.
  2. The server responds with the 401 "Unauthorized" response code, providing the authentication realm and a randomly generated, single-use value called a nonce.
  3. At this point, the browser will present the authentication realm to the user and prompt for a username and password. The user may decide to cancel at this point.
  4. 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.
  5. 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 :

GET /dir/index.html HTTP/1.0
Host: localhost

.
; Server response:

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




Error


401 Unauthorized.





; Client request :

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"

.
; 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

.
----
The "response" value is calculated in three steps, as follows. Where values are combined, they are delimited by colons.
  1. The MD5 hash of the combined username, authentication realm and password is calculated. The result is referred to as HA1.
  2. 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.
  3. The MD5 hash of the combined HA1 result, server nonce, request counter, client nonce, quality of protection code and HA2 result is calculated. The result is the "response" value provided by the client.
Since the server has the same information as the client, the response can be checked by performing the same calculation. In the example given above the result is formed as follows, where MD5 represents a function used to calculate an MD5 hash, backslashes represent a continuation and the quotes shown are not used in the calculation.
Completing the example given in RFC 2617 gives the following results for each step.
HA1 = MD5
= 939e7578ed9e3c518a452acee763bce9
HA2 = MD5
= 39aff3a2bab6126f332b942af96d3366
Response = MD5
= 6629fae49393a05397450978507c4ef1
At this point the client may make another request, reusing the server nonce value but providing a new client nonce. For subsequent requests, the hexadecimal request counter must be greater than the last value it used – otherwise an attacker could simply "replay" an old request with the same credentials. It is up to the server to ensure that the counter increases for each of the nonce values that it has issued, rejecting any bad requests appropriately. Obviously changing the method, URI and/or counter value will result in a different response value.
The server should remember nonce values that it has recently generated. It may also remember when each nonce value was issued, expiring them after a certain amount of time. If an expired value is used, the server should respond with the "401" status code and add stale=TRUE to the authentication header, indicating that the client should re-send with the new nonce provided, without prompting the user for another username and password.
The server does not need to keep any expired nonce values – it can simply assume that any unrecognised values have expired. It is also possible for the server to only allow each nonce value to be returned once, although this forces the client to repeat every request. Note that expiring a server nonce immediately will not work, as the client would never get a chance to use it.

The .htdigest file

.htdigest is a flat-file used to store usernames, realm and passwords for digest authentication of Apache HTTP Server. The name of the file is given in the.htaccess configuration, and can be anything, but ".htdigest" is the canonical name. The file name starts with a dot, because most Unix-like operating systems consider any file that begins with dot to be hidden. This file is often maintained with the shell command "htdigest" which can add, and update users, and will properly encode the password for use.
The "htdigest" command is found in the apache2-utils package on dpkg package management systems and the httpd-tools package on RPM package management systems.
The syntax of the htdigest command:
htdigest passwdfile realm username
The format of the.htdigest file:
user1:Realm:5ea41921c65387d904834f8403185412
user2:Realm:734418f1e487083dc153890208b79379

SIP digest authentication

uses basically the same digest authentication algorithm. It is specified by RFC 3261.

Browser implementation

Most browsers have substantially implemented the spec, some barring certain features such as auth-int checking or the MD5-sess algorithm. If the server requires that these optional features be handled, clients may not be able to authenticate.
Because of the disadvantages of Digest authentication compared to Basic authentication over HTTPS it has been deprecated by a lot of software e.g.: