With all the talk of HTML 5 around the corner, I’ve been thinking of how passwords are sent over HTTP. Let’s not forget that SSL is pretty much busted now that anyone can sign a certificate. If you wanted to avoid your passwords being stolen while someone monitors your connection, a site has to have a custom client-side component. These components usually send a salted hash (such as MD5) of the password instead of the plain-text password.
This is a pretty good method, but relying on Javascript or heavier components like Flash, Java, or ActiveX could be avoided if the HTML and browsers adopted a newer forms encryption model. It would be nice to have the server push some a key to the user for a form field and have the browser perform the hashing.
Some might argue that this isn’t something that should be done by HTML, and I can see where they are coming from, but remember that form encryption does currently exist – and is so weak it’s practically worthless. It requires almost no work to see passwords as plain-text, and anyone at all who is monitoring a connection for that purpose probably has the tools to see the decrypted passwords.
There are large dictionaries of most hashes available, some over 1 Terabyte in size, but this isn’t a concern with this proposed idea. The hash is salted with data provided by the server. In order for a hash lookup table to be useful it would have to be exponential in size and targeted at a specific sites algorithm for generating salts.
No Comments