3 ms·

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

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