I don't see how implementing (correctly) an already known one-way hashing function (SHA/MD5 for example), and then using this to form part of a basic challenge-handshake protocol is not better than sending the password over the wire.
In this way the attacker would be unable to gain anything useful from seeing the challenge or handshake packets, and the only remaining vector is some form of keylogger.
Under the heading That attack sounds complicated! Surely, you're better off with crypto than without it?
"Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request. Intercepting requests does not require advanced computer science. Once an attacker controls the web requests, the work needed to fatally wound crypto code is trivial: the attacker need only inject another <SCRIPT> tag to steal secrets before they're encrypted."
This seems to happen whenever Javascript crypto is brought up. It's crazy. SSL a little bit of work and it costs $ to purchase a cert (but not very much). It's a bit more CPU overhead on the server but most people have cycles to spare. For the most part SSL should be no big deal.
What am I missing here? Are people to cheap to purchase an SSL cert? Theoretically the PKI is only as trustworthy as the CAs but that can't be why people are acting like SSL/TLS isn't even an option.
Challenge-response hashing in JS is MitMable and likely to have implementation errors.
SSL has defenses against MitM attacks, and is implemented in very widely-deployed libraries, so if there's an implementation error you'll hear about it before it's used on you.
The drawback is of course that you need to have a signed key. That is the price you pay for MitM resistance. We're not supposed to use self-signed keys (which are free), even though they are strictly better than JS challenge/response hashing.
Under the "Really? Why?" section, start with the first point:
If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code. The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.
You don't have to anything that sophisticated; you can just intercept one of the HTTP requests that builds the page and insert code to steal the passwords.
In this way the attacker would be unable to gain anything useful from seeing the challenge or handshake packets, and the only remaining vector is some form of keylogger.
Or am I missing something here?