When your web page uses HTTP any form content is passed to the server as plain text. This means that there is a possibility or someone intercepting the data as it is passed to the server. When it is critical that such interception not be able to happen the solution is to use HTTPS with a security certificate. The content of the form is then encrypted in the browser using the security certificate and the encrypted data is then passed to the server.

Only the server is able to read the encrypted data because only the server has access to the other part of the security certificate that is used to do the decryption.

Someone concerned enough about security to want to try to make it impossible to intercept the data but not concerned enough to want to get a security certificate proposed a JavaScript solution for trying to protect passwords (they were unconcerned about the other data in the form, they just wanted to apply additional security to the password field).

Now most systems looking at password security store a "hashed" version of the password in the database. A hash is a code of a specified length that is based on the content of the text passed to it. The calculations done to generate the hash make sure that a small change to the source results in a totally different hashed value. By storing the hashed value of the original password and then hashing the password again each time it needs to be checked and comparing the hashed values means that no one with access to the database content where the password is stored can tell what password any given person is using.

This helps to protect those people who use the same password on multiple sites since obtaining the hash value from one site doesn't provide you with the original password to try to use it on other sites. The same input value doesn't necessarily produce the same hash on different sites because the code can add additional content to what is to be hashed before hashing it. This additional content is known as a salt.

The proposed solution was that where the browser has JavaScript available the browser convert the password to a hash using JavaScript and pass the hashed version rather than the plain text version. The server would then detect which format the password had been sent in and only hash passwords passed from browsers without JavaScript before comparing the hash with the value in the database.

My first argument against this approach is that the chances of a "man in the middle attack" (as these interceptions are called) is fairly small and that where the damage that such interception can cause is high enough to need protecting against then the HTTPS solution is the way to go since that is the only one that works for everyone. Also a small script to perform the hashing in JavaScript will be at least 2k or more in size which is a rather large JavaScript given the small amount of additional security that it would provide by hashing the password before sending it.

The discussion was about to become an argument over whether a 2k script is large or not when I realised that there was a second argument against using that approach. While hashing the password before sending it prevents the man in the middle from obtaining the original password, it doesn't add any extra security to the site that the password in logging into. With that hashing in place the hashed version of the password will serve the man in the middle just as well to break in to the site as the original plain text password would since the server needs to be able to accept either version as being the password.

I still disagree that adding all this extra JavaScript into a web page in order to try to protect a password from a man in the middle attack is worthwhile and still recommend that anyone requiring that protection use a security certificate. I have however thought of a way of limiting the usefulness of an intercepted hashed password.