> For example Hacker News learns my password to this web site every single time I sign in because that's just a secret.

I don't know the details of the login system for Hacker News, but i would expect they learn "a hash of your password and some salt" for every login, and your password isn't just transmitted to them. If they're doing things correctly, they're only storing a hash of your password, and can't work backward to get it -- that's a big If, and lots of places get it wrong.

▲

tialaramex 14 hours ago | parent | next [-]

> I don't know the details of the login system for Hacker News, but i would expect they learn "a hash of your password and some salt" for every login

No. That would be a terrible idea and so that's not what they do. You can go see for yourself, it's an HTML form, the text field with your password in it is submitted to their web server, much in the same way this larger field full of comment text was sent.

If you think a bit harder you'll realize why your approach would be a bad idea. A bad guy who has obtained the password hashes (for example by dumpster diving, or an SQL extraction) can just play back a hash they've seen without ever knowing your password, you've rendered the knowledge of the password useless.

Yes, that means if you've been around long enough, sites which had passwords but did not use TLS or before that SSL, were sending your actual password, unencrypted, for any snoop to see. That might seem crazy, but because I'm an old man when I first used the Internet it was normal to send your password, letter by letter in plain text, to connect to a remote Unix machine. The "Secure Shell" you take for granted today did not exist until July 1995.

	▲	fc417fc802 13 hours ago \| parent [-]
		That's not a bad idea and I believe it is how any modern not-a-website password based authentication works. Agreed that it does not address the attack vector of someone sniffing your password for site A and then logging into site A with it. However a key stretching algorithm (as opposed to just a hash) combined with salt does protect against an attacker logging into site B if the user reused his password. Of course for a website and assuming TLS then in practice it doesn't make much difference whether the hashing takes place client side or server side since an attacker sitting on the server could presumably serve up a compromised frontend. And without TLS a MITM could again compromise the frontend. But hashing client side does at minimum prevent the service operator from accidentally logging plaintext passwords, and anyway not all services are web apps. An attacker can't trivially change out the frontend if it's an app on my phone.

▲

DaSHacka 15 hours ago | parent | prev [-]

I've never actually found a site that computes the hash client-side and sends the finished hash to the server, the vast majority just send the regular password to the backend to be hashed and compared (and HN is no exception).

And if you think about it, there's really no advantage to sending the hash every time anyway. An attacker that MITMs your traffic once can just resend the static post-computed hash to the backend anyway.

The only advantage would be preventing an attacker from seeing a password string you may re-use for other sites, but so long as it's unique for HN alone (surely we all use password managers on here? :-) ) it doesn't matter.