> Unencrypted usernames, passwords, and user IDs

I am shocked... SHOCKED!

Actually, I'm not. Maybe, I should be?

Commence anecdote: When evaluating which of 2 positions to accept, I settled on {CompanyX} because of the CTO, who seemed like an excellent person to learn from. Something like 20 years in leadership & a linux chops that I'll probably always be envious of.

By the time, I'd accepted the offer & taken 2-weeks to get settled into a new town, he'd left the company (quite the surprising red-flag for me)... but was still monitoring Github as part of the changing of the guard.

The first issues I filed at {CompanyX} was "we are sending passwords in cleartext(!!!)".

It wasn't 5 minutes before CTO-LINUX-GURU shouted me down. "IT'S HTTPS, NOT CLEARTEXT!". His message was sharp, and the obvious subtext was that I was dumb.

Well, if you say so... I let it go, and kept my head down.

Months later, we had to reset a bunch of user accounts because those passwords were being logged (in cleartext) to emails, and also saved to error logs when users had a difficulty logging in.

After 8 months with the company, I'd finally had enough. 2 months after I left, the friends I made there called me to tell me they were looking for work. The company had run out of money, and laid off a bunch of engineers.

I mean... It sounds like he was right, in the sense that sending passwords verbatim over HTTPS is completely normal and fine.

Obviously (not) logging cleartext passwords is the kind of thing you learn in Security 101.

The thing you learn in Security 102 is that you should encrypt passwords in HTTPS anyway, because so much of your middleware will assume fields aren’t secured, and will happily log them — that while from a theory standpoint, password-over-HTTPS is fine, in practice it’s a liability due to organizational issues.

You can securely send plaintext over TLS, but it’s best not to when avoidable — precisely because it’s inviting the disaster above.

Client-side encryption is security theatre. If clients encrypt the password, then an attacker can send a log-scraped hash just as easily as a plaintext one. If anything, the faults (like the one above) would still exist and just become harder to spot.

So the way I read this, “sending” is an ambiguous statement that could be really ok, or really bad.

1. Sending in clear text over HTTPS from the login form to validate authorization: normal and OK, this simply is how auth works. Here the user sends the password, not the site, though it is via the frontend.

2. Writing/storing cleartext password on the server/in DB/as part of a logline, and (inevitably) revealing it later when reading said stored data for some other innocent purpose (server is sending the cleartext password which it should have no record of and has no legitimate use for).

Good hashes are by definition a one-way, irreversible means to authenticate without leaking actual credentials. Storing the actual passwords anywhere in the system is tempting fate.

So what was the actual situation?

A) The password was being sent in full to the server, over HTTPS?

B) The password was being sent in full to the server, over a plain text (unencrypted) channel?

It sounds like the CTO was claiming the former (A).

If you are running JS on the client anyway, then it seems reasonable to pass the client the salt, and ask only for the hash of the salted password.

But, if you say it's never OK to send the full (unhashed) password over HTTPS, then this implies it's not OK to have a fully server-side web app with password authentication. Because the only way to validate the password is for the client to send the whole password (unless you only ask for specific characters, but then password storage gets harder).

Hashing the password in the client isn't very effective because the hash of the password now is equivalent to a password. If you have the hash you can just send it to the server and authenticate. Implementing this looks like a lot of trouble with little to no benefits, since you also have to take the regular precautions server-side anyway.

Sorry, perhaps I wasn't clear enough.

I wasn't arguing FOR hashing the password before sending it. My point was this: even if we think it's reasonable to require that a password be hashed before being sent over HTTPS, the corollary is that all web apps must use JS, and can't be server-side-code-only. And this corollary doesn't seem like a reasonable thing to require.

Your point that 'Hashing the password in the client isn't very effective because the hash of the password now is equivalent to a password.' is true if there's no salt, and if the password is never re-used across sites.

If the password is salted before being hashed and sent by the client, then having read-access to the plain text of the exchange only gives the attacker the ability to log in to that one site. Even if the same username/password combo is in use on other sites, the attacker can't use the password on those sites, because she can't hash the unknown password with an arbitrary salt.

Anyway, I'm definitely not an expert on this topic, so take what I wrote above with a pinch of salt (ha!).

My only reason to comment was that I was thinking through 'never send passwords' from first principles, and it struck me that, if everyone were to accept this to be true, they would also never willingly/knowingly log in to any site that works without JS.

Doesn't that require client side crypto - which was, last time I checked, widely regarded as being rather risky?

Sorry, I wasn't suggesting people do that. Just saying that, if you believe people must do that, then you're also saying every site must use JS.

Sending passwords over HTTPS is fine, but storing them in plain text is not. Hashing should always be done on the server side, with great care taken not to leak or log plaintext passwords (see Facebook).

Isn't it normal to send passwords over HTTPS? This is usually how login and password reset work. Obviously you have to be careful they don't get logged.