ch13: Digest Authentication
Last updated
Last updated
Digest authentication has not been widely deployed.
Use HTTPS instead.
"Never send the password across the network", use digest of the password instead.
A digest is a "condensation of a body of information".
Digests act as one-way function.
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.
A simplified three-phase handshake of digest authentication:
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.
Digest algorithms: MD5 (default) and MD5-sess.
The chunk of data called A1 is a product of secret and protection information, such as the username, password, protection realm, and nonces.
Algorithms:
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=auth or auth-int:
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.
The next nonce value can be provided in advance to the client:
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.
Suggested:
The client can also authenticate the server.
The qop field may be present in all three digest headers: WWW-Authenticate, Authorization, and Authentication-Info.
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.
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.
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.
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
Algorithm
A1
MD5
A1 = <user>:<realm>:<password>
MD5-sess
A1 = MD5(<user>:<realm>:<password>):<nonce>:<cnonce>
qop
A2
undefined
<request-method>:<uri-directive-value>
auth
<request-method>:<uri-directive-value>
auth-int
<request-method>:<uri-directive-value>:H(<request-entity-body>)
