The hashing should be done in the client's browser. The plaintext password should never reach the server (which is capable of sending emails).
If the browser hashes the password, that just makes the hash the plaintext password. You've accomplished nothing.
By sending the hash and never letting the plaintext password hit the air, the worst that can happen is breach of your login system, you will not be responsible for someone in a coffee shop with wireshark sniffing out people's passwords, which can be applied to multiple websites.
IE, doing this is a mistake because you may be smart but you probably haven't put your secure connection through everything that SSL has been put through.
On account creation,
password -> hash -> | -> stored
Logging in,
password -> | -> hash -> compare
Hence, if someone intercepted my hash, it's the same situation as if they looked in /etc/passwd on a multi-user Unix system. That is, it's more information than nothing, but it's non-trivial to use that information to figure out my password.
Is there a flaw in my reasoning?
What does this scheme protect you against, compared to the normal technique (part #2 in your example)?
Like on a Unix login, I have to provide the actual password to the service. But measures can be taken to ensure not only is the password itself never stored, but even that the memory that contains the password is appropriately zeroed after use. It's not a matter of the user trusting the service, it's a matter of the service being cautious with itself.
Password hash function is h. Client creates password p, hashes it 1000 times.
Account creation: Client sends h^1000(p) to server in the clear. Server stores h^1000(p) in plain text. Attacker eavesdrops h^1000(p), which is useless.
Log in: Client either looks up h^999(p), or calculates it from scratch starting at p. Client sends h^999(p) to server in the clear. Server hashes this to get h^1000(p), which matches what it has stored. Server replaces stored value of h^1000(p) with h^999(p). Client is permitted to log in. Attacker eavesdrops h^999(p), which is now also useless.
Log in 2: Client either looks up h^998(p), or calculates it from scratch starting at p. Client sends h^998(p) to the server in the clear. Server hashes this to get h^999(p), which matches what it has stored. Server replaces stored value of h^999(p) with h^998(p). Client is permitted to log in. Attacker eavesdrops h^998(p), which, again, has become useless.
...
Once the client gets down to around h^100(p), server (which has also been keeping count) starts prompting client to create a new password before the hashes run out.
(If you run out of hashes, you're screwed. You can log in one last time by sending p in the clear and having it stored in plain text. Attacker eavesdrops p, which is useless here but may be extremely useful elsewhere for obvious reasons. After this, you can never log in again.)
NOTE: obviously this assumes the hash function is irreversible, mostly free from collisions and quick to execute. Also, the user should ideally NOT log in like 1000 times in a week. Both achievable goals, though.
That aside, the only thing it gets for you are less code-paths you have to worry about that handle the password in plaintext. It's an application of the principle to only communicate what is strictly necessary to function.
http://en.wikipedia.org/wiki/Hash_chain
The resemblence is actually spooky. I swear I've never read that article before now.
Except that now the hash is your password, as far as the system is concerned. If someone intercepted your hash they could just pass the hash off to the site and they have full access. This isn't quite as bad as accessing the plain-text password (which potentially is shared across multiple sites) but it's still bad.
Also, there's an easy workaround for this problem, using SSL for login.
Similarly, someone can compromise my account on a Linux box if they get root access. They won't know my password, but they can change my password or just replace the login program with their own. But we consider getting root access a higher target that compromising a single account.
In other words, this is begging the question.
edit: I must have responded to a different understanding.
I did in fact read the article, and I do now agree that you only need to send MD5(username:realm:password) to the remote server to do the authentication.
The problem that I do see is that it is trivial for a MITM to either intercept the transaction and force the client into a less secure mode (ie. basic auth), and then read in the password, or else just reuse the auth credentials for another transaction.
I would recommend that you look at http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol and the concept of a "zero knowledge password proof" which seems to be the concept you were looking for.
Incidentally your snideness is not appreciated. Generally something doesn't get to be a widely implemented RFC without the obvious questions having been asked and answered.
But if you want such a ridiculous requirement, you can have JavaScript on the signup form that computes the hash on the client and sends it to the server. That form still needs to go over a secure channel (eg https) because the information sent, while not including the plain text password, is sufficient information for a sufficiently motivated attacker to get access.
Your reply, coming where it did in the thread, gave the impression you thought digest auth somehow avoided ever sending a plaintext password to the server.
Also, please do not use hash(x + y), use hmacs. String concatenation in hashing breaks some of the complexity guarantees and will lead to your hashes getting cracked faster then you'd expect.