Am I right to say that this won't work if the password is not stored in plain text on the server? I fail to see how the server could verify the hash if the password is already hashed (with salt and pepper) on the server.
This scheme does require the password to be stored in clear-text. Very bad.
Can this scheme be extended to work with hashed passwords somehow?
I'm sure it can, but there's no need. The scheme you've referenced is the HTTP digest authentication protocol. It was written in a day when SSL was considered to expensive to implement in many systems. Digest authn provided a way to login over clear-text channels without exposing the password. There's absolutely no reason to do that anymore. SSL is now effectively free.
In general, the risk of storing passwords on the server is considered to outweigh the benefit of having the server not having your password in memory for a short period of time (time from reception of password message until hashing begins and the cleart-text password's memory can be erased).
There are some situations where client-side hashing can make sense. For example, LastPass implements a unique authentication mechanism that involves both client and server hashing. They do this because they use your password as the basis for creating your encryption key and they never want the server to know your encryption key. So what they do is:
- Many rounds of PBKDF2 on client to create a strong encryption key.
- One round of SHA-256 to turn encryption key into what is effectively your password.
- Send password to server. Note that the properties of SHA-256 make it computationally impossible to reverse the password back to your encryption key.
- Server performs standard server-side hashing using PBKDF2 and salt.
Basically, the LastPass server does standard password storage but what it gets as a "password" is the result of client-side hashing.