All 1 entries tagged Http
No other Warwick Blogs use the tag Http on entries | View entries tagged Http at Technorati | There are no images tagged Http on this blog
October 04, 2005
You may want to skip this entry; unless you're interested in HTTP it won't be terribly interesting. I'm testing out the theory that writing something down is a good way to understand it, since this is about the third time I've tried to get Digest Auth to stick in my head.
So, here goes:
Digest authentication (spec ) is one of the standardised HTTP authentication mechanisms. It was designed to protect against some of HTTP Basic's more egregious failings (such as the fact that it passes the user credentials in plain text )
At it's most basic, it works as follows
- Client requests a resource which is protected.
- Server responds with HTTP 401, and the header line
WWW-Authenticate: Digest realm="Some realm", domain="/urlspace",nonce="long_random_string"
- client re-submits the first response, this time with an additional header
Authorization: Digest username="user",
response="md5 hash of username, pwd, uri, method, and nonce"
- Server verifies hash and serves response.
The optional qop (Quality of Protection) parameter in the www-authenticate header specifies which additional safeguards are to be used. In particular, if qop=auth-int is specified by the server, then the client returns a cnonce (client nonce) value, which is used as part of the hash. This stops a malicious proxy from specifying a nonce value designed to make cracking the hash possible.
Most implementations refine this by using a nonce that varies with time. However, there are some performance issues to consider here; if you vary the nonce on every request then parallel (pipelined) requests become impossible. Since virtually every browser now supports pipelining, this will have a fairly serious impact. The optional nc (nonce-count) attribute in the Authorization header allows the server to periodically supply a fresh nonce for further use.
Digest authentication more or less completely disables proxy cacheing, unless the response is marked as 'Cache-control: public' or 'Cache-control: must-revalidate' (in the latter case, the cache must HEAD the request back to the original server to verify before serving to the client).
Whilst digest authentication does provide reasonably good protection of user credentials, and (with a sufficently short-lived nonce), can also prevent replaying of requests, it does nothing to protect against packet-sniffing to extract content. For this, HTTPS is required. (In which case, many of the motivations for not using Basic go away).
Client support for digest authentication is good in modern browsers, but pretty shonky in V4 and earlier user-agents.
So, in summary:
- HTTP Basic BAD
- Digest Better
- HTTPS + Basic good
- HTTPS + Digest not appreciably better.