[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.