> If you hash passwords on the client, you aren't doing hashing right! If you hash passwords on the client, all an attacker needs is a user's hash, and then he

> If you hash passwords on the client, you aren't doing hashing right! If you hash passwords on the client, all an attacker needs is a user's hash, and then he can send it to you and get logged in without ever knowing the user's password. It doesn't matter if the server gets a password or a digest, as long as it can verify it. Hashing on the client side is obviously superior to hashing on the server side, since the original password is never transmitted over the wire. It is for the same reason protocols like SRP exist. (If you're worried about somebody compromising your digest database and logging in with those digests, you can just hash them with a cheap function like SHA-256 on the server side. There is no reason for the server to use an expensive function since the client has already stretched the input.) Unfortunately, SRP doesn't do key stretching, so it is trivial to brute-force the original input if you get a hold of the verifiers. But there'd be nothing wrong with e.g. a client-side scrypt mechanism that uses TLS for the transport, or even SRP/TLS-SRP (although you would need your server to manage/sync the salt.) It just hasn't been feasible so far since no efficient implementations have been available to web applications. What you should take away from password hashing is that it exists primarily to protect users from themselves. If everyone used unique passwords with 256 bits of entropy for everything, we wouldn't need it. We need it because they use weak passwords, and they use the same ones in many different places. If your server gets owned, it likely doesn't matter whether they can log in with contents of the database or not--they're already inside, and can probably easily find another way. What matters is that by making it expensive to brute-force the original input of possibly thousands of your users' passwords, you make it very hard/cost-ineffective (if you do it properly) for an attacker to compromise many/all of their other online accounts. PS: Digest auth as it exists today is a joke. It uses no stretching whatsoever, and is thus trivial to brute-force, whether by a MITM or an attacker who has gained access to the server's digest database.