On the topic of protecting passwords in web requests, LiveJournal's done something I've thought would be pretty cool for a while:
Challenge/Response
If your browser supports JavaScript (almost all do), then the login page won't send your password in the clear either. Instead, the server sends a "challenge" which your browser combines with your password with JavaScript and generates a "response" which can't be reversed. Your browser then sends that (instead of the password) and the server checks to see if the result is what it expects. If your browser can't do JavaScript, you can alternatively log in via SSL instead, and the interface will give you a link to do so.
Interesting: Brad says here they can't hash passwords in the database, as that would make challenge-response impossible--but where the c/r for clients is described, it uses MD5(password) instead of the raw password, so that the client doesn't need (and the server isn't required to need) to keep the unhashed password around. That still has the cross-site problems I mentioned in the previous post. You'd get that if you use a password on any site where it's sent totally in the clear anyway... but with so many folks perhaps imagining using an MD5(password) is magic pixie dust, hewing to his previous statement would narrow that potential hole.
Also interesting that ciphergoth posts a more erudite version of "OMG NO NO NO" when it seems to me to be a pretty common, standard, obvious thing. Not that I saw the exact thing in Applied Cryptography, but I'm curious what'll be in ciphergoth's proposed update.
