Basic Password Handling

This afternoon I signed up to a new web-based application from a very well-known media company. I gave them my email address and the password that I wanted to use and a few minutes later I got an email from them confirming my registration.

That was fine. But then I noticed that the email from them contained the name of their site, my username and my password. All in plain text. This is a breach of basic internet security processes. And thinking about it, I’ve seem several similar breaches recently. So I thought it was worthwhile making a note of some of the rules you should be following when handling users’ passwords on web sites and in emails. A sort of “Password Handling 101″.

Rule 1: Don’t Store Plaintext Passwords

This is the fundemental principle that all the other rules follow from. It is non-negotiable. If I give you a password to use on your web site then I should be the only person who knows it. I don’t want it stored unencrypted in your database so that any of your staff can look it up.

“But,” you say, “if it’s encrypted, how can we check it against the password you give us when you log in?”

“Easy,” I reply, “you do it the same way that Unix passwords have been checked for decades.”

You store the password using some encryption algorithm. The stronger the better. Then when I give you a password for you to check, you encrypt the new password using the same algorithm and compare it against the encrypted version in your database. If the two encrypted strings match then I’ve given you the correct password and you can log me in. Simple isn’t it?

“But,” you say, “if it’s encrypted, how can we tell you what it is if you forget it?”

“Simple,” I reply, “you don’t.”

If I forget my password then you have two options. Option one is that you generate me a new password, email it to my registered email address (but see rule 2 below) and store an encrypted version of the new password in your database. Option two is that you send (to my registered email address) a link to a web page where I can enter a new password. This link should obviously be time-limited (so I can only use it for a few hours) and should contain some encrypted key so that no-one can guess what the link is. The second option is less secure as anyone can intercept the email and get access to the link, so the first option should be prefered.

Rule 2: Username and Password Travel Separately

The problem with internet email is that (unless you use something like GPG) everything is in plain text and anyone can intercept it and read it. It’s like you are sending every letter on a postcard rather than in an envelope. For this reason you should never put the username and the password in the same email. The forgotten password scenario above should be the only reason why you ever send a password to a user in an email. So don’t put the username in that email as well.

Rule 3: Web Pages with Passwords Should Use HTTPS

Like email, by default, all web traffic is unencrypted. Anyone can potentially read anything that you send to a web site. So when I log on to your site and I enter my username and password, anyone can potentially intercept those values and that will enable them to log on to your site as me. If you serve login pages using HTTPS instead of just HTTP then that login transaction will be encrypted all the time the data is on the public internet and it will be much harder for anyone to extract my login details.

Three simple rules that every web site should be following. And it’s surprising (or, at least, it surprises me) how many sites don’t follow these basic rules. Following these rules won’t make your site impervious to people determined to break into in, but it will go a long way to making your users’ accounts more secure.

I was going to name and shame the site that I dealt with this afternoon, but I wrote them a polite email explaining the problems and in less than 45 minutes I got a reply saying that these problems had already been noted and that they should be fixed by the end of the week. That’s pretty good customer service so I won’t embarass them by telling everyone who they are.

11 thoughts on “Basic Password Handling

  1. Ta-da list from 37signals is bad at this. 37 dickheads more like it! It emails your password back to you if you forget it, and doesn’t log in with a secure connection either. Oh yes, and the user interface is abysmal too. Quite why this company is held up as a darling of the new economy I will never know.

  2. Yet another example. Palisade software, who make the @Risk Excel plugin for doing Monte Carlo simulation, emails your password back to you as soon as you join their support forums. This type of problem seems very widespread. I hope these companies feel named and shamed!

  3. IIRC, Mailman (Python mailing list manager) has a distressing habit of sending your username and password to you once a month. But I haven’t gotten one of those in a while, so perhaps the feature has been removed in recent versions. Or maybe I’m not on any Mailman lists any more.

  4. Ah yes. Mailman. I’d forgotten about that.When you sign up to a mailman mailing list it does tell you that it will send your password to you in plain text and warns you not to use a “valuable password”. And I think that in later versions you have the option to turn off the automatic monthly password reminder emails.But, yes, all in all they have a ridiculously cavalier approach to passwords.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>