The idea is that both sides prove that they know the same secret. The server sends the browser a challenge string called a nonce. The browser's reply contains both the nonce and an MD5 hash of various information including the nonce and its secret. The server satisfies itself that the nonce was valid, and tries to do the same hashing calculation. If the server and browser come up with the same answer, then they knew the same secret, and have managed to verify this without ever saying the secret.

The vulnerability to things like replay attacks is controllable on the server side in how it produces and verifies what the nonce was. Even if you can do a replay, you cannot use it against other pages because the complete requested URI is part of the hash. So a man in the middle can get the same page that they saw flying past a second ago.

Incidentally the shared secret is: Digest::MD5::md5_hex("$user:$realm:$password") So the server doesn't have to keep the actual password, but if you have used a one-way encryption mechanism which is incompatible with the above, then you will not be able to transparently move users to Digest authentication.

(Or at least this is how I read the documentation after scanning it quickly.)

Good description of Digest encrytption from what I remember about it. I'd just like to add a slight addition though..

If I remember correctly from what I read in Applied Cryptography (My copy is currently on loan, alas) if required a nonce can be strengthened by adding an accurate timestamp, request counter, or other non-repeating series.

By using Digest::MD5::md5_hex("$user:$realm:$password:$series_id") as the nonce, and keeping track of 'used' nonces and rejecting them it stops the man-in-the-middle even being able to use replay attacks to see those pages that just flew past them.

After all, would you really want someone to replay your entire session for shutting down your database server when they so choose?

That is what I meant by the phrase, The vulnerability to things like replay attacks is controllable on the server side in how it produces and verifies what the nonce was.

However it is good to make it clear how you avoid replays, and why you would want to.

Just a side note. Hashing the user, realm, and password to create the shared secret does not provide the same protection the hashing in standard password files. The hash is the shared secret so anyone who retrieves the password database can use the secret to authenticate. They don't need the brute force the plaintext password like the password files.

The advantage is that they don't acquire the plaintext password and can't use it to login into any other services that use the same password.