As far as I understand the answer at https://security.stackexchange.com/a/3024/13447, client nonces are meant to prevent attackers from amortizing the costs of brute-force hash computations by being able to reuse the computations results
- for multiple users and/or
- for multiple servers
However, even in the simplest Digest Authentication variant (qop = none), the
username and the
realm (supposedly unique per server) and the
nonce (more than just unique per server) are included in the data that gets (usually MD5) hashed.
Doesn't this already make reusing of precomputed hashes across users/servers impossible?
So a client nonce would only add to security, if https://www.rfc-editor.org/rfc/rfc2617#section-4.9 is correct:
The ability to choose the nonce is known to make cryptanalysis much easier .
But that same section then goes on to say
However, no way to analyze the MD5 one-way function used by Digest using chosen plaintext is currently known.
This is a statement from 1999. Since then, various collision attacks have been published for MD5, but none which would help in this case, if I'm not mistaken.
What am I missing?
Update I guess it makes sense to spell out what we are talking about exactly. In the most basic form of Digest Authentication the client calculates and sends to the server the result of the following:
MD5(MD5(username + ":" + REALM + ":" + password) + ":" + NONCE + ":" + MD5(http-method) + ":" + uri))
Except for the password, all values are also sent in plain text.
To make it more clear, variables whose values are set by the client are lowercase, whereas variables the client retrieves from the server are in uppercase. (This makes my 'realm and nonce' fallacy above, pointed out by David Wachtfogel immediately obvious, as a MITM can freely choose those uppercase values, assuming the realm is not checked by the client, which, judging from the "sophistication" I've seen in most admin's passwords, would be the norm, rather than the exception).
Btw, the value of the uri is supposed to be an absolute uri, like
http://servername/path?query, and thus would globally unique, however, that depends on the client's implementation and whereas Opera implements it that way, the versions of Chrome, IE, Firefox I tested do not, and rather just use '/path?query' (afaict this is in violation of https://www.rfc-editor.org/rfc/rfc2617#section-126.96.36.199).
So whether a precomputed table would be reusable across servers depends on the client implementation, and if the MITM can choose, it will of course prefer the weaker browsers to Opera, if he has a precomputed table.