If you can't do SSL, just do plaintext passwords. It means you're being open with your users about the risk.
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.)
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?)
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.