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.

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.

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.

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.

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

There is a technology for doing something like that

https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

but it's not what's commonly used in website authentication.

Usually no.