April 12, 2010

Atlassian and web password security

Update: Atlassian have taken a deep breath, composed themselves, and written a thoughtful and considered piece on what happened, how they reacted, and what they’ve learned. Go and read it, because there’s a lot of useful stuff in there

So, a disappointing day today. I got an email from Atlassian, makers of fabulous software development tools, as follows:

We are sending you this message because we experienced a security breach and suspect that your Atlassian customer account password details (only) may have been compromised. [...] Be aware that this security issue only affects Atlassian customers who created an Atlassian account and purchased one of our products before June 2008. Since then, we have been using a more secure user management system based on Atlassian’s Crowd product.

Now, this is just lame. It would appear that Atlassian have been storing passwords in clear-text in their database. This, by itself, is pretty inexcusable, but what’s even worse is that they were running a “more secure” system alongside it, but for whatever reason didn’t bother to migrate old accounts into it. Thanks guys.

What’s so disappointing about it is that Atlassian aren’t just some crappy rate-my-kitten-pictures website*. Every experience I’ve had with their tools (and I speak as someone who uses almost everything they sell) leads me to believe that they are really clever guys. They make brilliant software that I and the rest of my team depend on every single day to do our job.

If they were a dog, they’d be a prize-winning, trials champion sheepdog that’s just crapped on the kitchen floor. Bad Atlassian. In your kennel, now.

All of which leads me on to the lesson for today. It’s an oldie but, apparently, still needs reiterating every now and again.

DON’T STORE PASSWORDS IN PLAIN TEXT

That’s it, really. There is absolutely no excuse, ever, for doing this. Every single language in the world has a library hashing implementation that you can use, so use it. Hash with a random salt, and use a slow algorithm like blowfish if you can, but please, just hash it. Don’t encrypt it, because that means that somewhere you’ve got a decryption secret, and if I can get hold of that then I’ve got all your passwords in plain text.

And if you ever find yourself in the position that Atlassian are in, don’t do what they’re doing in the email above, and gloss over the most important message, which is this:

Change your password on every site which uses the same email address + password combination.

Sure, in a perfect world everyone would use a different password for every site, and the makers of OnePassword would be trillionaires, but in the real world they don’t and (as far as I know) aren’t. People re-use passwords, and once you’ve shared those passwords with the hacker community at large, you owe it to your users to remind them of that.

Oh, and one more thing. If you’re making a website with self-signup capabilities, please offer support for OpenID, or some other distributed authentication standard that I’m likely to have. If you’re not sure how that should work, go look at how StackOverflow do it. Then ask yourself; do I really need to demand a username and password from you at all?

* No offence to icanhazcheezburger.com, who I’m sure do a bang-up job of password security, though I don’t have an account with them myself.


- 3 comments by 1 or more people Not publicly viewable

  1. Si

    It’s a little unfair to assume that Atlassian stored your password in plain text. Even if it were ‘just’ a username + salted password hash dataset that was compromised, it would still be good policy to advise customers to change their passwords.

    12 Apr 2010, 22:30

  2. Mathew Mannion

    I got the same email (June 2008 is presumably just after they did their offer to get Jira for a fiver) and I am still baffled about how they could store passwords in plain text and then didn’t migrate to the new system. All I can think of is that they use a relatively common hash (MD51) and they didn’t use to salt their passwords, which makes a rainbow table attack2 completely trivial for a large percentage of passwords. It would then not be possible to migrate users to the new system.

    While this won’t cover myself in glory as a web developer who occasionally has to dabble in detail storage (don’t worry general public, I am a lot more careful with your data) I actually only have a small number of passwords and I tend to have one of them as an “insecure” passwords that I use to sign up to sites that don’t store financial details (not that any site should store financial details). At some point you just have to accept that the effort people have to go to to steal your identity or compromise your accounts is always going to be relatively small – is the data stored on these sites really important enough to justify the man hours to keep every single set of details isolated from the next?

    Email addresses are published by users, dates of births are easily gleaned from Facebook or calendars (even if they’re not your own) or public CVs, a person’s mother’s maiden name and place of birth are stored in databases that can be easily accessed by pretty much anyone3, as are the schools they went to. Most people store passwords in their web browser without a keyring password (and even if they do have a password to the data store, they have to be encrypted, not hashed). Directgov’s website requires two passwords, a user-specified question/answer combination, a memorable date that isn’t your birthday and a unique number that is mailed to you on a card in the post – making it pretty much impossible to go back and use it again after 6 months unless you write all the information down in a single place, which is potentially even less secure than just having a password.

    This is not a new problem (think of the security implications of regular old snail mail, handled by relatively low-paid strangers who may or may not be trustworthy) and short of some kind of hardware solution (personal seeded random number generator, key pair combinations based on biometrics) it is pretty much unsolvable. No matter how good your hashing algorithm is and how uncrackable it is (you could make it effectively impossible to infer the password from the hash) the problem is still going to exist between keyboard and chair.

    1 http://en.wikipedia.org/wiki/MD5

    2 http://en.wikipedia.org/wiki/Rainbow_table

    3 http://www.direct.gov.uk/en/Governmentcitizensandrights/Registeringlifeevents/index.htm

    13 Apr 2010, 00:34

  3. Jon Silvers

    Chris and Matthew (and anyone else following this thread), you’re absolutely right to be disappointed. We have no good excuse for it. We just published a long blog post about the security breach, why it happened what we know about it so far. http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html There is still more detail to come. Our apologies for the breach as well as the poor communications that followed.

    - Jon

    13 Apr 2010, 00:53


Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Trackbacks

Most recent entries

Loading…

Search this blog

on twitter...


    Tags

    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXIV