[IncreasePosts]

This is why I always hash passwords client side before sending them to my servers. That way, when I store them in plain text, I can say it is just the hash and not the password itself!

On a relevant note, how is this fine amount determined? Were there any damages?

[dgrin91]

Can't tell if your being sarcastic or not. Now your hashes are just the passwords. Your server can't unhash them, so anyone intercepting your traffic effectively has the password.

[IncreasePosts]

I was being sarcastic, but, why wouldn't client-side hashing of passwords prevent some class of attacks that can be used when plaintext passwords are accidentally stored(and eventually exfiltrated) - eg credential stuffing?

[Neywiny]

Because you've just changed what the password is. For example if your password is X, with hash Y, the server identifies Y as your password. Then I come along and steal Y. The server has no concept of X, so to the server you and I are equally valid in being you. We both present the hashed password Y.

[lesuorac]

Isn't there still an advantage of hash Y is now known and is like abcd1234 while the password X (hunter2) remains unknown?

So while you can still authenticate as the user to say facebook you can't login to their linkedin account. Assuming, facebook and linkedin don't use the same client side salt.

[squeaky-clean]

But you gain the downside that if your password database gets leaked, now every users' password is there in plaintext. All you have to do is bypass the hashing function in the client-side login so you can send whatever hash you have in your database leak.

You could hash them again before they hit db, but then your not really pre-hashing the passwords clientside. And if you want to change your hashing algorithm or parameters, users can't login until they update their clients.

[cocoa19]

Yes, it’s an advantage if you plan to store plain text, but storing plain text is bad to begin with.

There is no advantage if you use proper security practices like storing a hash and salt.

[lesuorac]

I mean this sounds like a "you'll never have a bug if you just program well" argument.

Whoever created the login system probably is a different person than who added the logging system. Perhaps the logging system should've discarded login attempts or masked the credentials but there's probably a dozen ways to login and they'd need to know all of them and possible futurely added ones.

It seems a bit more practical to have the system send a safer version of a parameter to the server instead.

[IncreasePosts]

Clearly "Y" is just the password as my server sees it

But, by not sending the actual user-entered password, it prevents me from logging the user-entered password in plaintext.

If I did make a mistake and logged the users email and "Y", and I got hacked, the hacker could not take the email and "Y" and try to log into a variety of other online services using the same credentials. This is the credential stuffing I was speaking of.

[YetAnotherNick]

There are people who just append password with the name of site or something relevant to site. Like "mypasswordfb". It would prevent guess google's password as "mypasswordgoogle"