You're thinking about this the wrong way. It's not supposed to buy you security. It's supposed to protect the user. (Yes, in the narrow case where an attacker h

You're thinking about this the wrong way. It's not supposed to buy you security. It's supposed to protect the user. (Yes, in the narrow case where an attacker has access only to your accounts table, and you want to prevent them from being able to log in as a user, hashing helps, but that can be separate from the stretching--a normal hash function will do just fine to prevent someone from simply presenting a digest to your login mechanism.) As you just said, there is no difference between using a password or a hash digest, since the server just needs to verify either of them. So, using a hash digest from the client (generated by a strong password hash function) is superior since an attacker, whether a MITM or somebody who has compromised your servers, will have to spend a lot of time and money extracting the original password if they get a hold of the digest. The reason we currently generate these on the server side is not that it is more secure--in fact it is terribly insecure if somebody compromises the communications channel or the server itself, since they will be able to read the original, plain-text password--but rather that it is cumbersome, for now, to do it on the client side.