Practice Cryptography!

Another important problem in cryptography and encryption practice that was recently brought up on the NSS mailing list is the problem of "man in the middle" attacks in SSL and TLS -- from the view of the server.

With the way that SSL and TLS handle various aspects of the protocol, it's nigh-impossible for the server to be forged to the client. (This is mostly due to the requirement that the server present a trusted certificate to the client.)

However, the same cannot be said for the reverse path. Since clients do not have certificates (as a general rule), anyone who can capture the data provided by the client to the server can replay that data. (Historically, this hasn't been viewed as a problem, but in these days of worms and viruses and keyloggers and rootkits, the client side is now more vulnerable than the server to attack. Since SSL and TLS only protect the wire protocol from eavesdroppers and malicious intruders, the data is unwrapped at either end of the connection. Servers generally have fairly stringent safeguards as to how the information they process is controlled -- but clients have to deal with users running code that they really shouldn't be.)

As well, there's just too damned many problems with client certificates as they stand anyway. Have to export private keys and certificates to move them from machine to machine (exposing them to rogue processes), have to import them (and hope the new machine isn't running any rogue processes), have to do this for every machine that is used, thus allowing credential information to be stored on many machines when security best practice says "keep it on one machine with one backup"...

There are many issues associated with this; however, one possible solution could be a "temporarily loosely bound" keypair... where the client presents a self-signed certificate with no information other than the public key to the server, and the server builds a new 'identity' from that keypair... gradually adding elements as they're learned, as the server can identify and authenticate the credentials. Then, when the user logs out of the server's context, the identity information associated with that public key by the server can be cleared.

This would prevent the problem of a man-in-the-middle attack for as long as that session lasted, but there needs to be a more reliable and more useful "one-time password" or time-based authentication system (as an example, RSA's SecurID) to prevent the credentials from being stolen by malware.

Some of the research in this field (preventing malware from gaining passwords and such) is actually being done by online game companies, such as MapleStory Global [must use MSIE to access]. Within their game client, they have a "PIN" system that randomizes the location of numbers on an on-screen keyboard, and the user must click in their PIN in order to log in. Combined with another technology which prevents the process from having a debugger attached to it (if you attempt to debug the process, the secondary thread is notified and immediately kills the game client), this helps reduce the ability of key- and mouse-loggers to steal login credentials.

Will this help? Eventually, even this will probably be gotten around. It's a constant arms race -- but it would certainly be helpful for banking applications and the like.