Whatever the server receives, it should do all the good things, salted hashing and what-have-you. But no one says what it receives needs to be a plaintext password.
Hash on the client side before sending- unsalted, or salt there as well and pass it along to the server- but let's just ensure that the server never has the ability to see a plaintext password. It can't log it, it can't accidentally leak the plaintext.
Will that solve all problems? Oh, hell no. But it at least strengthens the mitigation against certain attacks or mistakes.
If you hash, with or without salt, on the client for changing the password, you'll also need to hash identically when checking it (i.e. for login). In effect, the hash becomes the password; even if the plaintext is never leaked the first-level hash is just as good for access.
Right, but if a hacker releases a password dump for site X, no one has your password in plaintext, just the log in hash. That said, that solution requires JavaScript.
Yes, but then the attacker can ignore your JavaScript and just send the hash value they got from the dump. If you calculate hash(password) and send that for comparison to the hashed password stored in the user database, then hash(password) is your password from then on.
Whatever the server receives, it should do all the good things, salted hashing and what-have-you. But no one says what it receives needs to be a plaintext password.
Hash on the client side before sending- unsalted, or salt there as well and pass it along to the server- but let's just ensure that the server never has the ability to see a plaintext password. It can't log it, it can't accidentally leak the plaintext.
Will that solve all problems? Oh, hell no. But it at least strengthens the mitigation against certain attacks or mistakes.