ch13: Digest Authentication
1. The Improvements of Digest Authentication
Digest authentication has not been widely deployed.
Use HTTPS instead.
1.1 Using Digests to Keep Passords Secret
"Never send the password across the network", use digest of the password instead.
1.2 One-Way Digests
A digest is a "condensation of a body of information".
Digests act as one-way function.
1.3 Using Nonces to Prevent Replays
To prevent replay attacks, the server can pass along to the client a special token called a nonce.
The client appends this nonce token to the password before computing the digest.
This prevent the replay attack.
1.4 The Digest Authentication Handshake
A simplified three-phase handshake of digest authentication:
2. Digest Calculations
2.1 Digest Algorithm Input Data
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 two pieces of data, A1 and A2, are processed by H and KD to yield a digest.
2.2 The Algorithms H(d) and KD(s, d)
Digest algorithms: MD5 (default) and MD5-sess.
2.3 The Security-Related Data (A1)
The chunk of data called A1 is a product of secret and protection information, such as the username, password, protection realm, and nonces.
Algorithms:
Algorithm | A1 |
MD5 |
|
MD5-sess |
|
2.4 The Message-Related Data (A2)
The chunk of data called A2 represents information about the message itself, such as the URL, request method, and message entity body.
A2 is used to help protect against method, resource, or message tampering.
Quality of protection (qop):
qop | A2 |
undefined |
|
auth |
|
auth-int |
|
2.5 Overall Digest Algorithm
qop=auth or auth-int:
2.6 Preemptive Authorization
In normal authentication, each request requires a request/challenge cycle before the transaction can be completed, this is depicted in Figure 13-4a.
This request/challenge cycle can be eliminated if the client knows in advance what the next nonce will be, so it can generate the correct Authorization header before the server asks for it. This is depicted in Figure 13-4b.
2.6.1 Next nonce pregeneration
The next nonce value can be provided in advance to the client:
2.6.2 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.
If a nonce finally expires, the server returns 401:
with stale=true.
2.7 Nonce Selection
Suggested:
2.8 Symmetric Authentication
The client can also authenticate the server.
3. Quality of Protection Enhancements
The qop field may be present in all three digest headers: WWW-Authenticate, Authorization, and Authentication-Info.
4. Practical Considerations
4.1 Multiple Challenges
If a server does not know the capabilities of a client, it may provide both basic and digest authentication callenges.
When faced with multiple challenges, the client must choose to answer with the strongest authentication mechanism that it supports.
4.2 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.
4.3 Rewriting URIs
Proxies may rewrite URIs in ways that change the URI syntax but not the aatcual resource being described.
Digest authentication sanity checks the integrity of the URI value, the digest authentication will break if any of these changes are made.
4.4 Caches
When a shared cache receives a request containing an Authorization header and a response from relaying that request, it must not return that response as a reply to any other request, unless one of two Cache-Control directives was present in the response:
must-revalidate
public
Last updated
