6 ms·

> Unencrypted usernames, passwords, and user IDs I am shocked... SHOCKED! Actually, I'm not. Maybe, I should be? Commence anecdote: When evaluating which of

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

johnday 7y ago
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.
- FakeComments 7y ago
  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.
  - johnday 7y ago
    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.
rahimnathwani 7y ago
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).
- arethuza 7y ago
  Doesn't that require client side crypto - which was, last time I checked, widely regarded as being rather risky?
  - rahimnathwani 7y ago
    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.
- roro159 7y ago
  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.
  - rahimnathwani 7y ago
    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.
kpeekhn 7y ago
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.
JTbane 7y ago
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).
cwmoore 7y ago
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.
- 420codebro 7y ago
  Couldn’t some JavaScript code compute the hash/salt client side to enable never sharing the plaintext to begin with?

johnday 7y ago

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.

FakeComments 7y ago
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.
- johnday 7y ago
  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.

rahimnathwani 7y ago

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

arethuza 7y ago
Doesn't that require client side crypto - which was, last time I checked, widely regarded as being rather risky?
- rahimnathwani 7y ago
  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.
roro159 7y ago
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.
- rahimnathwani 7y ago
  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.

kpeekhn 7y ago

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.

JTbane 7y ago

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

cwmoore 7y ago

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.

420codebro 7y ago
Couldn’t some JavaScript code compute the hash/salt client side to enable never sharing the plaintext to begin with?