[niftich]

I don't follow what you're saying.

To compare your new password with your old password, you take the old salt, hash your new password together with it, and compare the result to the old hash. If they match, you're trying to reuse the same password. You do this on the server side, naturally.

[ikeboy]

If everything is done server side, sure.

[niftich]

Why wouldn't it be?

If salted hashing were done on the client side, it means you're actually sending username + saltedhash, instead of username + password to the server to log in.

So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.

[ikeboy]

>Why wouldn't it be?

So that the server never gets any plaintext.

>So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.

You could hash once on the client and once on the server to get the best (?) of both worlds. Really only the server one needs to be salted.

[icebraining]

I don't see what hashing on the client gets you.

[ikeboy]

>So that the server never gets any plaintext.

Mitigates attacks that exploit the server but not the served js.

See also https://security.stackexchange.com/questions/53594/why-is-cl... for some discussion: the first answer has the same thing I proposed, hashing on both the client and server.

I guess another benefit might be constant size passwords, which may mitigate side channels or sniffing.

How can it hurt? If there's no harm, but some upside, then why not?

[icebraining]

Since the resulting hash must be deterministic, you can't use a salt, and since you may login from crappy smartphones without JIT engines, you can't use many rounds. So the resulting hash will be trivially cracked using rainbow tables. The problem of variable-length passwords is better solved by only allowing the use of block ciphers in your TLS configuration, which you should probably do anyway.

As for the disadvantages, it makes logins take longer, forces the use of JavaScript, increases the complexity of code and increases the site size.

[rlidwka]

You can store this hash on the server and use it as a password. If this hash gets stolen, the attacker will be able to log in on YOUR website, but not on other websites user may share passwords with.

After that you can ditch server-side hashing, and use authentication protocol like CRAM-MD5 (I don't remember what the modern alternatives are) to protect against network traffic interception. While still not technically storing your users' passwords in the database.

EDIT: Using asymmetric crypto with a private key derived from the password would probably be better. But still, client-side hashing DOES gain you something.