That's very true. Damnit. Not sure how I'm going to fix that.
I've looked into public-key encryption, and unless if I generate a new public and private key for every request to login, replay attacks are still possible.
If you hash the password on the clientside, say, and then use that as the password in your scheme throughout, then you don't need to transmit the password in cleartext, ever.
This is a win because, even though you're sending something password-equivalent over the wire, at least you're not exposing a password that's used on other applications?
Precisely. For all the hackers ignoring it, there stands the simple fact: people reuse passwords over and over again, for bank accounts, email, and everything else. I don't know what the stats are, but I'd bet if you randomly query people in, say, your or family, you'll find quite a few. At least I did.
So while capturing a password over HTTP and replaying it gives access to someone's karma in a site like this, once you actually know the plaintext password you could, for many people, use it to break into otherwise secure sites (even using SSL), like gmail. This has serious reprecussions.
Finding a password over the wire is just like finding password: <something> in a closed drawer. Sure, you don't know what it's for, but were you malicious, you'd be able to try a host of different places.
Can we have it both ways? Transmit a password-equivalent over the wire, without compromising the security of the password database?
How about using a cryptographically strong hash on the client side, transmitting that hash to the server, and then having the server perform another cryptographically strong hash on the hash it receives, and compare that against its database? This way, the server isn't storing the passwords in the clear anywhere, and there is still at least some protection against having users' passwords picked out of the air -- even, I think, during the user's initial registration.
I realize that any client-side code designed to do this can be compromised by a man-in-the-middle attack, forcing the user's password out into the open. This isn't meant to be perfect security, it's just meant to provide one extra layer of protection for the individual user's password(s), without compromising the database as a whole.
It still leaves the problem of password sniffing over an unsecured network, but I think that could be solved by generating a salt on the server for each login request, and then transmitting that salt to the client, where it's used to re-hash the password-equivalent. That would also help protect against something like a DNS compromise, since effectively every user's password changes every time they log in.
There are still plenty of ways to break this scheme, but I think at this point it's Sufficiently Hard (tm) enough to be suitable for an online forum.
...and I imagine that somewhere, tptacek is screaming, "Just use SSL!"
I mean, there are a few standpoints here: if you're running a site, use SSL, if you're a user, don't reuse passwords or use something like PWDHash, or if you're working on a browser or you're an admin, consider a way, like PWDHash, of making it so that a password compromised at one site doesn't compromise any others.
I've looked into public-key encryption, and unless if I generate a new public and private key for every request to login, replay attacks are still possible.