Jason's blog post ("How Not to Do Website User Registration") certainly attracted a lot of comments! I think articles like this exceed my expectations about this blog. Back before we had "blogs", we had the Internet Storm Center diaries, which are still going strong. I always felt that the best diaries are the diaries that don't have all the answers, but diaries that stimulate discussion and feedback.
With that comes the need to sometimes step back and consider that I don't have all the answers. In particular, we have to keep in mind that we don't secure websites just for themselves, but we secure websites so they can fulfill a function. 32 characters random passwords, which have to be changed daily, are just not the solution. I am always interested in ways to make software more secure without impacting usability. The way I sometimes put it: "Security is not about preventing a breach, security is about staying in business".
Now how does this apply to website registration and encrypted passwords? A dilemma I always had: I hash all my passwords in the database. I use SSL to transmit the password and cookies. But I hardly ever encrypt the password itself as it is transmitted from the browser to the server. You may say: Wait! We got SSL for that! Right, but remember SSL is just protecting the password. The website still ends up processing the clear text password. What is needed is a way to encrypt the password on the browser before passing it to the server.
HTTP actually has a decent way to encrypt passwords, called Digest authentication. But it has other problems and is not really an option for many sites.
The server stores the nonce in a session, and can do the same calculation using the password hash stored in the database.
This way the server is only exposed to the original password during the account creation and whenever the password is changed. You may ask why anybody would care about their ISC password... well, maybe if they use the same password for their online banking, I just don't want to touch it. Information becomes a liability pretty quickly in these cases and sometimes you have to protect the users from themselves.
So here my questions:
- Is this effort worth it? Am I fighting a real threat or am I just an obnoxious security fanatic?
- Are there other solutions?
- What did I do wrong? Any holes in this scheme? (I do consider sha1 good enough for this case)