This is not really ideal either, because the hash becomes the password. If an attacker got the hashes from your DB, he would only need to send the stolen hash to the server to authenticate.

The ideal way to deal with passwords would be something like SCRAM [1], but you are adding a bunch of complexity on the client side, and you'd need to trust your JS libraries.

[1] https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...

Hashing it on the client side doesn't really have any positive effect on security as the client must then know what salt is used for the hash. This is less secure than just hashing on the server as the salt and number of hash iterations is then unknown by the client (or potential attackers).

I disagree.

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.

Yes. I agree. My point is I don't want to ever see plaintext on the server in any form. It won't stop everything, but it's still worth doing.

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.

Yes, but they can't then use the dumped passwords on 300 other websites.

Isn't the salt not necessarily supposed to be impossible for the attacker to find out though? like isn't it usually like the username, since it needs to be different for each user but not impossible for the server to figure out?

I'd agree if the client in some way exists independently of the server. For example, if you have a smartphone app, then client-side hashing could be useful.

But for a web page, what's the point? The server is in full control of the JavaScript they send you. If the server is compromised, it can easily bypass the client-side hashing by sending your browser different code.

Either way, this is a password strength checker, sending just a hash to the server would be useless.

Client-side password strength checker would make it functionally impossible to check dictionaries.

Sorry, as I keep saying in this thread, the excellent client-side password strength checking library zxcvbn (https://github.com/dropbox/zxcvbn) is under 400 kB compressed including dictionaries, checking against "30k common passwords, common names and surnames according to US census data, popular English words from Wikipedia and US television and movies, and other common patterns like dates, repeats (aaa), sequences (abcd), keyboard patterns (qwertyuiop), and l33t speak"

Thus, it is, as a matter of fact, quite possible to do reasonable password strength checking on the client side with a footprint that's a small fraction of many of today's ad-infested websites.

If you hash it you can't determine the "strength" of the password except maybe looking up the hash in a rainbow table.

Do your strength checks in javascript client-side, then hash, then send. Server side can do further checks if it wants on the hashed password (hey, this password was already used, etc).

any clientside validation can easily be bypassed using something like fiddler.

Password strength checking is (properly understood, in my view) providing help to the user, not enforcing some silly and annoying "password validation" rules.

How would you even validate the password server-side if you're salting it at the client level?

With that approach you would also need to be mindful of pass-the-hash vulnerabilities.