HTTP The Definitive Guide (Digest Authentication)

Digest Authentication

The Improvements of Digest Authentication
In particular, digest authentication:

• Never sends secret passwords across the network in the clear
• Prevents unscrupulous individuals from capturing and replaying authentication handshakes
• Optionally can guard against tampering with message contents 
• Guards against several other common forms of attacks

Using Digests to Keep Passwords Secret
The motto of digest authentication is “never send the password across the network.

One-Way Digests
The 128 bits of MD5 output often are written as 32 hexadecimal characters, each character representing 4 bits.

Using Nonces to Prevent Replays
To prevent such replay attacks, the server can pass along to the client a special token called a nonce,* which changes frequently (perhaps every millisecond, or for every authentication). The client appends this nonce token to the password before computing the digest.

Digest authentication requires the use of nonces, because a trivial replay weakness would make un-nonced digest authentication effectively as weak as basic authentication. Nonces are passed from server to client in the WWW-Authenticate challenge.

The Digest Authentication Handshake
The HTTP digest authentication protocol is an enhanced version of authentication that uses headers similar to those used in basic authentication. Some new options are added to the traditional headers, and one new optional header, Authorization-Info, is added.

Digest Calculations
Digest Algorithm Input Data
Digests are computed from three components:

• A pair of functions consisting of a one-way hash function H(d) and digest KD(s,d), where s stands for secret and d stands for data
• A chunk of data containing security information, including the secret password, called A1
• A chunk of data containing nonsecret attributes of the request message, called A2

The Algorithms H(d) and KD(s,d)

The two algorithms suggested in RFC 2617 are MD5 and MD5-sess (where “sess” stands for session), and the algorithm defaults to MD5 if no other algorithm is specified.
If either MD5 or MD5-sess is used, the H function computes the MD5 of the data, and the KD digest function computes the MD5 of the colon-joined secret and nonsecret data. In other words:
    H(<data>) = MD5(<data>)
    KD(<secret>,<data>) = H(concatenate(<secret>:<data>))

The Security-Related Data (A1)

The Message-Related Data (A2)
RFC 2617 defines two schemes for A2, depending on the quality of protection (qop) chosen

• The first scheme involves only the HTTP request method and URL. This is used when qop=“auth”, which is the default case.
• The second scheme adds in the message entity body to provide a degree of message integrity checking. This is used when qop=“auth-int”.

Overall Digest Algorithm

• The first way is intended to be compatible with the older specification RFC 2069, used when the qop option is missing. It computes the digest using the hash of the secret information and the nonced message data.
• The second way is the modern, preferred approach—it includes support for nonce counting and symmetric authentication. This approach is used whenever qop is “auth” or “auth-int”. It adds nonce count, qop, and cnonce data to the digest.

Digest Authentication Session

Preemptive Authorization

Here are three potential ways a client can obtain the correct nonce without waiting for a new WWW-Authenticate challenge:

• Server pre-sends the next nonce in the Authentication-Info success header.
• Server allows the same nonce to be reused for a small window of time.
• Both the client and server use a synchronized, predictable nonce-generation algorithm.

Next nonce pregeneration

The next nonce value can be provided in advance to the client by the Authentication-Info success header. This header is sent along with the 200 OK response from a previous successful authentication.

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

Limited nonce reuse
Instead of pregenerating a sequence of nonces, another approach is to allow limited reuse of nonces. For example, a server may allow a nonce to be reused 5 times, or for 10 seconds.

When the nonce finally expires, the server is expected to send the client a 401 Unauthorized challenge, with the WWW-Authenticate: stale=true directive set:

WWW-Authenticate: Digest
                               realm="<realm-value>"
                               nonce="<nonce-value>"
                               stale=true

Synchronized nonce generation
It is possible to employ time-synchronized nonce-generation algorithms, where both the client and the server can generate a sequence of identical nonces, based on a shared secret key, that a third party cannot easily predict (such as secure ID cards).

Nonce Selection
RFC 2617 suggests this hypothetical nonce formulation:
    BASE64(time-stamp H(time-stamp ":" ETag ":" private-key))

Symmetric Authentication
RFC 2617 extends digest authentication to allow the client to authenticate the server.
The response digest is calculated like the request digest, except that the message body information (A2) is different, because there is no method in a response, and the message entity data is different. The methods of computation of A2for request and response digests are compared in Tables 13-6 and 13-7.

Quality of Protection Enhancements
The qop field may be present in all three digest headers: WWW-Authenticate, Authorization, and Authentication-Info.

Message Integrity Protection
If integrity protection is applied (qop=“auth-int”), H (the entity body) is the hash of the entity body, not the message body.

Digest Authentication Headers
Both the basic and digest authentication protocols contain an authorization challenge, carried by the WWW-Authenticate header, and an authorization response, carried by the Authorization header. Digest authentication adds an optional Authorization-Info header, which is sent after successful authentication, to complete a threephase handshake and pass along the next nonce to use.

Practical Considerations

• Multiple Challenges - A server can issue multiple challenges for a resource. For example, if a server does not know the capabilities of a client, it may provide both basic and digest authentication challenges. When faced with multiple challenges, the client must choose to answer with the strongest authentication mechanism that it supports.
• Error Handling - In digest authentication, if a directive or its value is improper, or if a required directive is missing, the proper response is 400 Bad Request.
• Protection Spaces - The realm value, in combination with the canonical root URL of the server being accessed, defines the protection space. The specific calculation of protection space depends on the authentication mechanism:
• In basic authentication, clients assume that all paths at or below the request URI are within the same protection space as the current challenge. A client can preemptively authorize for resources in this space without waiting for another challenge from the server.
• In digest authentication, the challenge’s WWW-Authenticate: domain field more precisely defines the protection space. The domain field is a quoted, space-separated list of URIs. All the URIs in the domain list, and all URIs logically beneath these prefixes, are assumed to be in the same protection space. If the domain field is missing or empty, all URIs on the challenging server are in the protection space.

• Rewriting URIs - Proxies may rewrite URIs in ways that change the URI syntax but not the actual resource being described. For example:
• Hostnames may be normalized or replaced with IP addresses.
• Embedded characters may be replaced with “%” escape forms.
• Additional attributes of a type that doesn’t affect the resource fetched from the particular origin server may be appended or inserted into the URI.
• Because URIs can be changed by proxies, and because digest authentication sanity checks the integrity of the URI value, the digest authentication will break if any of these changes are made.

• Caches

Security Considerations

• Header Tampering
• Replay Attacks
• Multiple Authentication Mechanisms
• Dictionary Attacks
• Hostile Proxies and Man-in-the-Middle Attacks
• Chosen Plaintext Attacks
• Precomputed dictionary attacks
• Batched brute-force attacks
• Storing Passwords