No security scheme delivered over Javascript is going to make a difference in a security audit. Your auditor is going to tell your prospective customer that anybody who controls the DNS, routing, the network, ARP, the browser --- or 10 other places --- can rewrite the Javascript in transit.
If you can't do SSL, just do plaintext passwords. It means you're being open with your users about the risk.
Attacks that require an in-flight rewrite of the client side element of the authentication method are several orders of magnitude more difficult than wire sniffing for passwords, which is not an insignificant barrier when we are talking about a 15/30 minute at-the-coffee shop attack window.
Wire sniffing won't work in a properly implemented scheme as the server doesn't trust the client in any way. All it does is accept transactions that contain appropriate authentication tokens that can be independently verified by the server. This means that your attack would need to insert a hook into the JavaScript to push the contents of any password field to a box under the attacker's control.
(Assuming there is a shared secret between server and client (eg, a password set up over SSL) then CHAP can provide authentication without the shared secret ever being available on the wire without it being (salted+hashed). The language used to implement the system makes no difference (provided you have a good source of random numbers available on at least the server, and a strong hash function). Even if you can't do SSL to set up the password this still has value over plain text, as it allows people to set up passwords on trusted connections (corporate LAN, wired ISP) and not expose them on untrusted networks (coffee shop wifi) to the most common form of attack - passive logging.)
"Wire-sniffing passwords" is far more difficult than redirecting traffic. I think you're totally off.
CHAP, by the way, is a bad protocol. It's mutual-auth challenge-response, and there are a bunch of gotchas to implementing it. Even the trivial challenge-response protocols proposed on this message board are better for web auth than CHAP.
(Edit: apart from my tone [heh], I wonder if readers are recoiling from the idea that something they can do on the command line with "tcpdump" is "hard". If you're trying to collect 1000 passwords, which machine do you crack to see 1000 sessions?)
Technically speaking, the first thing any decent security auditor will tell you is that certain security mechanism making or "not making a difference" depends solely on a threat model.
Challenge-response authentication protects against passive attacks (such as sniffing). Rewriting Javascript in transit implies an active attack scenario. In a majority of cases, yes, the active attacks are a part of a threat model, but there are deployment scenarios where they are not.
I'm no expert... but what if just the javascript was served via https? Maybe somebody ought to put an MD5 javascript library on an https server as a public service. Or would js hashing still be vulerable since the man-in-the-middle could change the nonce or something?
If you're going to serve Javascript over SSL, you need a full SSL setup including a valid certificate, etc. If you have that, you may as well just serve the login form itself over HTTPS, redirecting back to HTTP after logging the user in, and forget the Javascript altogether.
He means someone set up a a JS library over HTTPS on a server for _others_ to use. Like you would grab a JS library off of Google's HTTPS servers and use that on your non-SSL pages.
If you can't do SSL, just do plaintext passwords. It means you're being open with your users about the risk.