[sroussey]

Lots. But even those that don’t tend to send the password to the server, which is still bad.

[yetanotherjosh]

How is sending the password to the server over HTTPS bad? What would you do otherwise? Hash it on the client? So are you not using salted hashes for your password store? That's far worse. Or you're hashing twice, the first with no salt client-side, then again with salt on the server side, which is fine, but the client-generated hash must be unsalted so is basically just the password itself: steal the client-generated hash instead of the original password, just as good with only minor loss in value (might not be able to reuse it on other sites for the victim; but actually maybe still could if you can build a reverse index of common passwords hashed using whatever algo is in use.)

And if you don't trust HTTPS to protect sensitive information, why would you send the auth cookies over it that have virtually as much power the password that was given in exchange for them in the first place?

[Isinlor]

Why would you want to see actual user password if you can not see it?

If you see a password you can leak it by screwing up in numbers of ways. If you never see a password you just can't leak it.

E.g. Twitter recently discovered that they were storing passwords in plaintext in logs, GitHub had similar issue.

Take a look here: https://arstechnica.com/information-technology/2018/05/twitt...

Of course, a hash that you will recive from client should be treated as a normal password including all good practices.

[throwawaymath]

> Hash it on the client? So are you not using salted hashes for your password store?

There is no reason you can't also salt on the client. Salts do not need to be secret. The substantial constraint you outlined in your comment isn't a problem.