I've done this before in a site, probably badly. But the way I handled it is that on sign up I hashed the password on the client side and stored that once. Then during login as part of the form I also included a "challenge" (i suspect I was not rigorous with it) that went with it, so I had: HMAC(HASH(password), challenge), and that's what got sent across. Since the server had the original HASH(password) and the challenge it could verify that you knew the password without either the hash or password being sent. I know for a fact that I wasn't handling replay of the challenge properly but it wouldn't be too difficult to deal with it (add the time and have it expire after so long). But I definitely had other problems with it (no SSL, and probably bad sidechannel issues).
If we talk about "hash the password before sending to the server" this procedure is what we're talking about (or something similar). Surely people aren't thinking of literally just hashing the password and sending it on its merry way? If we say "symmetric encryption" we don't mean we're going to do AES(block_n, key) either (ECB mode should never be used for anything).
yea i think the bits i'd shoot for with this now are
1. Bcrypt(or scrypt, or similar) for initial hash of password. (used PBKDF2 i think before).
2. Add time expiration to the challenge-response
3. Rate limit the challenge/response per account
4. make sure to use a good hash for HMAC() (was using sha-1 since JS was much slower then).
Ideally I'd also have a single challenge/response token per user and not let you get several to try against (i.e. invalidate old ones) but I'm not sure how I'd make that scale well. Maybe a salt+counter put into a hash (like HOTP) and then after a token is used invalidate all tokens with the counter less than the most recently attempted version?
