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 fundamental 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 preferred.
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 embarrass them by telling everyone who they are.
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.
Getty Images also emails your password back to you. Oh dear.
And Bananalotto.com just emailed me my password without me even asking, totally out of the blue, in an attempt to get me to visit the site again!
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!
Ian,I hope you’re passing these complaints back to the site owners.Maybe we need a web site to list sites who are known to have bad password handling policies.
Funnily enough I’ve been thinking the same, so I finally got myself motivated and created http://badpasswordpolicies.tumblr.com/ yesterday.
Only one post so far; I’ve got a few of my own to add.
I’m definitely open to submissions.
I’d also like to link to your Marvel stories if you don’t fancy submitting them yourself.
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.
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.
you a thief give me back my password
I’ve seen poor password protection often enough in codebases that I wrote about it from a developers point of view:http://barkingiguana.com/2009/08/03/securing-passwords-with-salt-pepper-and-rainbows
WRT to rule 2.What if your username is your e-mail address?
Needed to reset my @Marvel account password. So they sent me my old one. Idiots – http://t.co/VHfa31oIAt
RT @davorg: Needed to reset my @Marvel account password. So they sent me my old one. Idiots – http://t.co/VHfa31oIAt
I once added an (extremely superficial but not-unappreciated) layer of security to a system by never having the email even say the word “password”, but instead “access key”, or “secret codeword”, or the like.
(BUT: This was a system where if the user couldn’t figure that out, then they were too stupid to be trusted to use the system. And incidentally, hundreds of people have used the system– and I never heard a word of confusion or complaint from anyone.)
Also, I often say: “The access key will be the first word of the next message you’ll get from me.”
…and then have just that next thing be a one-word message.
Like I say, superficial, but at least it makes it not among the very lowest-hanging fruit.
(Me saying “first word” is just so any appended “FORWARDED BY YAHOO MAIL HURRRRR” won’t be considered part of the password.)
I’ve thought of using ImageMagick to generate an image of the text of the password, and emailing that…
Or generating a heavily obfuscated file in some document format which, when opened in a relevant application, nevertheless does just express the code as the text: “]5q3W3_B”, in Times Roman or something.
I’m not sure if these actually gain any advantage, other than hopefully losing the attention of algorithms that assume that binary goo isn’t going to contain a password.
Advice is welcome.