I quote my comment on #24:
At the end, we really need the live version to use SSL. There's no good way around that.
For the time being, a few interesting proposals are possible:
- The simplest one is to md5 (or, in my preference, SHA512) the password on the client side prior to sending it, and thus never sending the actual password (which would then be hashed by PHP in a more secure fashion, resulting in all the benefits of the current system with one drawback fixed.
- However, this fix isn't what one might think. It would simply mean that the user's password couldn't be intercepted in transit and used on other sites - For GAMR, an attacker would just send the hash directly as authentication.
- This means that a more complicated system is needed. A rotating set of hash algorithms in use, such that the server and client always agree on which one to use, would block the trivial attack on the last method.
- This would work, kind of. The problem is, its complicated, and its not without its own, much smaller holes.
- A Diffie-Hellman key exchange could be performed. This would mean that the client and server never exchange the password, they just agree on what it is.
In the end, all of these would work much better in an environment with SSL/TLS in place. I recommend that live servers use these, if not always, then for registration and login. This, however, is its own issue (#25).
#24 was fixed in 0e4dd20 by applying SHA-3 (512 bit output) to the password prior to registration and prior to login, both on the client side. The server therefore never sees the valid password, nor would any theoretical man in the middle. This doesn't prevent a man in the middle from sniffing the hash and using it to connect, of course, but it prevents such an attacker from gaining access to the user's password and thus using it on other sites - At least, it helps make this more difficult, as for the time being reversing SHA-3 is extremely difficult in a practical amount of time.
However, it would be nice to find a way to keep an attacker from invalidly connecting to our service using a sniffed hash. This is the purpose of this issue: To find a way that protects better than this, while we fix #25, and to augment security in the (unlikely) case that SSL does not prevent an MITM attack.
I quote my comment on #24:
However, it would be nice to find a way to keep an attacker from invalidly connecting to our service using a sniffed hash. This is the purpose of this issue: To find a way that protects better than this, while we fix #25, and to augment security in the (unlikely) case that SSL does not prevent an MITM attack.