The Big Idea : Better Password Hashing

For the last couple of days I have been thinking about how browsers send passwords across the network. I think I have a safer way. I would have to work at Microsoft or Mozilla to get this implemented however, I am content with blogging about it and getting some feedback. This is a line of code that as a web developer I write all the time:

<INPUT TYPE=”TEXT” NAME=”Login” /><br />
<INPUT TYPE=”PASSWORD” NAME=”Password” />

This HTML delivers the login and password to the browser in clear text. The web application takes the password and concatenates it onto a stored piece of random text (called salt) and then hashes the complete string. This hash is compared with the hash store for that login and if they match then the web application can assume that the user knows their password. If the web developer implemented good security for his system then he never stores the password, only a hash of the salt and the password. The salt helps make every hash unique. Why do web developers hash passwords? Well, most people only have four to five passwords that they use on roughly a hundred sites. If one of those sites is compromised and the password is in clear text then that password can be tried on other sites to gain access as that user. It also limits the harm an employee can cause if they have access to every password. Since you don’t know if the web site you are entering your password into is storing it hashed or in clear text it is in your best interest to change your password for every web site. However, keeping track of all those passwords becomes a maintenance nightmare. If you can’t remember them all you will need to write them down – and then where do you store them to keep them safe? So here is the big idea: Why doesn’t the browser hash the password before it sends it to the web site? This way the user would know that the web site couldn’t store his/her password as clear text because the web site would never get the clear text from the browser. The web developer would just store what they get from the browser, the hash of the password and compare that hash every time the user logs in. If the browser is going to hash the password, it has to know the salt in order to create a unique hash. This is the tricky part. Every user needs to have a different salt and that salt needs to be the same for that user every time. The salt can’t change based on browser, or computer, or location of the computer. The salt must be different for each web site – since having the same salt and password would mean the same hash for every web site which is the same security risk as the same password stored as clear text. My suggestion is that the salt be the domain name of the site concatenated with the login. The domain name and the login are known by the browser when the form is submitted; it is always unique per user and would be the same no matter where they logged in from. Plus each salt would be different for each domain. An evil doer that compromised the web application reading the password hash from the web database wouldn’t know the hash for another web site. Basically it is the same as making the browser generate a unique password for every web site. How would the browser do this securly? How would the HTML have to be rewritten (i.e. how does the browser know which input is the login)? Would the DOM restrict client side scripting from reading the password? These are all questions I don’t have the answers for. However, I do know that password handling on hundreds of web site is going to be an issue that needs solving in the next four to five years. {6230289B-5BEE-409e-932A-2F01FA407A92}