4 ms·

> He asks me to go to Live.com (the Microsoft email site) and enter a random username and password. A few seconds later, the information I just typed appears on

> He asks me to go to Live.com (the Microsoft email site) and enter a random username and password. A few seconds later, the information I just typed appears on his screen. This was interesting - how? Shouldn't only the hash of the PW be sent over the network?

gsich 9y ago
Usually no.
schoen 9y ago
Web applications normally receive the real password on each login, but only store the hash in their long-term databases. In this case the attacker might have also been doing SSL stripping, which (1) would typically work even if it were an HTTPS site, but not if it had HSTS or an HSTS preload; (2) would also allow him to change the site's user interface so that it asked for or received information in a different way from usual. So even if a site didn't normally solicit or transmit some specific kind of information, the tampered-with version might do so, assuming the attacker had thought to prepare a modified version of that particular site.
- scrumper 9y ago
  Thanks, I figured some MITM for the SSL piece but genuinely thought that client side JS hashed the PW. So this was educational and I am uncomfortably naive.
  - schoen 9y ago
    There is a technology for doing something like that https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... but it's not what's commonly used in website authentication.
  - kqr 9y ago
    Once you start thinking in terms of using JS to hash the password it's very easy to end up reimplementing HTTPS in your own client code. Just a hash isn't going to do much because replay attacks, so you need additional measures in place. Just running HTTPS is way preferable to implementing your own HTTPS in JavaScript. But, of course, the larger problem is the password itself. No matter how you spin it with hashing or whatnot, a password is still a shared secret. You need to communicate a secret to the other party so they can verify it. You can almost hear how flawed a technology it is from the description, and I'm honestly surprised it has been allowed to exist for so long.
    - schoen 9y ago
      > No matter how you spin it with hashing or whatnot, a password is still a shared secret. You need to communicate a secret to the other party so they can verify it. There are lots of challenge-response protocols that prove knowledge of a secret without communicating it. A simple example would be that the verifier could ask for the HMAC of the shared secret under a randomly-generated HMAC key. The prover can reply with the correct HMAC, but neither the verifier nor an eavesdropper would be able to reconstruct the shared secret from this reply without previously knowing the secret.
jandrese 9y ago
Browsers don't hash the password field, it's just text. As for how he got around the HTTPS redirect on Live.com, I'm guessing it was a DNS poisoning attack to serve up a fake Live.com on HTTP. Presumably the journalist didn't have SSL Everywhere installed, because he's a tech journalist.

gsich 9y ago

Usually no.

schoen 9y ago

Web applications normally receive the real password on each login, but only store the hash in their long-term databases. In this case the attacker might have also been doing SSL stripping, which (1) would typically work even if it were an HTTPS site, but not if it had HSTS or an HSTS preload; (2) would also allow him to change the site's user interface so that it asked for or received information in a different way from usual. So even if a site didn't normally solicit or transmit some specific kind of information, the tampered-with version might do so, assuming the attacker had thought to prepare a modified version of that particular site.

scrumper 9y ago
Thanks, I figured some MITM for the SSL piece but genuinely thought that client side JS hashed the PW. So this was educational and I am uncomfortably naive.
- schoen 9y ago
  There is a technology for doing something like that https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... but it's not what's commonly used in website authentication.
- kqr 9y ago
  Once you start thinking in terms of using JS to hash the password it's very easy to end up reimplementing HTTPS in your own client code. Just a hash isn't going to do much because replay attacks, so you need additional measures in place. Just running HTTPS is way preferable to implementing your own HTTPS in JavaScript. But, of course, the larger problem is the password itself. No matter how you spin it with hashing or whatnot, a password is still a shared secret. You need to communicate a secret to the other party so they can verify it. You can almost hear how flawed a technology it is from the description, and I'm honestly surprised it has been allowed to exist for so long.
  - schoen 9y ago
    > No matter how you spin it with hashing or whatnot, a password is still a shared secret. You need to communicate a secret to the other party so they can verify it. There are lots of challenge-response protocols that prove knowledge of a secret without communicating it. A simple example would be that the verifier could ask for the HMAC of the shared secret under a randomly-generated HMAC key. The prover can reply with the correct HMAC, but neither the verifier nor an eavesdropper would be able to reconstruct the shared secret from this reply without previously knowing the secret.

jandrese 9y ago

Browsers don't hash the password field, it's just text. As for how he got around the HTTPS redirect on Live.com, I'm guessing it was a DNS poisoning attack to serve up a fake Live.com on HTTP. Presumably the journalist didn't have SSL Everywhere installed, because he's a tech journalist.