I don't understand your point. Even if the client sends HASH(password), that effectively becomes the credential. That's where HTTP Digest is less successful (as was pointed out by a sibling and I went D'oh for not remembering).
> At a minimum you should be hashing whatever the client sends and storing that.
That's a very narrow view of how to authenticate. SRP and client certs certainly don't work that way.
In SSL/TLS, the data is transmitted using a one-time pad of some kind, so that intercepting a transmitted token gives you nothing that you can use to authenticate in a future connection (but you might be able to hijack the connection you intercepted, if you spoofed the server into thinking you are the intended client)
Yes, there are many many more secure schemes out there. By minimum I meant minimum.
The point was what the client sends should not be what's in the database or easily reversible from what's in the database. I guess the larger point was you can't trust clients in any way shape or form.
