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.
