Hacker News Reader

Comment by rahimnathwani | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com