Everytime we submit a form over HTTP or HTTPS with our password, we present an opportunity for a man-in-the-middle to perform some voodoo and decipher our passwords. With SSL in shambles, and HTML Form “encryption” a complete obfuscatory waste of time, most of us turn to JavaScript to perform client-side authentication. I think authentication is pretty important, but I’ve not heard much about this relating to the proposed HTML5 specification.

The Problem

There are a lot of problems with web security, but the most important is when an attacker knows your password. It’s one thing for the attacker to compromise a key local to your server, such as by a replay attack, or through breaking your hashing algorithm(s), but to gain access to the plain-text password probably puts other accounts at risk. While we should all be using 100% unique passwords for every account we create, more importantly I think we shouldn’t be sending our password over the wire at all.

The Solution

As I mentioned, right now everyone is rolling their own implementations in JavaScript. Who knows how many different copies of MD5, SHA1, etc. are floating around in everyones caches. Nothing is shared, and browsers without JavaScript support are stuck in the plain-text password sending dark ages. As mentioned in this mailing list entry, support should be added to the INPUT tag in HTML. The effect would stop the contents of type=”password” elements from sending their contents, but instead send a Hash of the contents. The mailing list except also mentions using a Salt, which is probably worth doing, but I think the concept of a truly private key is warranted.

Shouldn’t HTTPS solve this?

Probably, but there is still no good reason to be giving out a plain-text version of your passwords.

Can’t an attacker just mitigate this?

This was a topic of debate during my conversations in the IRC channel. Indeed, a man-in-the-middle attacker that has control over content could modify the HTML to not include a hash attribute, and redirect the insecure form submission to another server, thus giving the attacker the plain-text password. This attack relies on the old technology, which should be deprecated, and eventually removed.

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.