Why your app’s security design could affect sales of Acai berries

Here’s the thing about securing credentials in web apps; you’re not just responsible for securing your application, you’re also responsible for securing your customer’s identities.

Let me demonstrate:

123456, password, 12345678, qwerty, abc123, 12345, monkey, 111111, consumer, letmein, 1234, dragon, trustno1, baseball, gizmodo, whatever, superman, 1234567, sunshine, iloveyou, fuckyou, starwars, shadow, princess, cheese

These 25 passwords were used a total of 13,411 times by people with Gawker accounts. The first one – 123456 – was used over two and a half thousand times alone.

How do we know this? Because every one of these passwords and hundreds of thousands more were stolen from Gawker last month and released into the wild where they are now readily accessible. Because people reuse their credentials, Gawker’s approach to application security didn’t just compromise their own data, it compromised an untold number of other applications.

The damage doesn’t end at Gawker

Gawker obviously screwed up on a fairly grand scale. There’s a lot of commentary out there about what they did wrong and how it lead to such a comprehensive breach, but what’s really interesting is the damage done beyond Gawker.

Shortly after the Gawker hack, Twitter become flooded with Acai spam. Why? Because evil-doers simply took compromised usernames, email addresses and passwords from Gawker, plugged them into Twitter and guess what? Many of them worked!

Of course the problem here is human in that many people simply create themselves a master username and password and reuse these credentials everywhere. There’s no arguing this is a big security no-no but there’s also no arguing that there’s very little we, as software developers, can do about this. Federated and second factor authentication services are great, but let’s face it – they have their own issues and how often are they actually used?

How many of the passwords above look “strong”? How many look like they could feasibly have been used on other websites? Other than the “gizmodo” one, I’d say the likelihood of reuse is rather high. Even the founder of Gawker used the same eight digit password for Twitter as he did his own company’s website!

In fact, the likelihood of password reuse was sufficiently high for LinkedIn, Yahoo and Blizzard (and probably others) to request potentially affected customers to reset passwords on their sites. This is serious indictment of internet security practices as it acknowledges the high propensity for password reuse and concedes that once an individual is compromised in one location, chances are they will be compromised in many locations.

Your responsibility goes beyond your application

This brings me to the point of this post; your responsibility stretches beyond your application. The do-gooder side of me would call this a “social responsibility”. The more pragmatic side would simply point out that the impact of the breach on Gawker’s customers became significantly worse when they were required to take action on totally unrelated websites. If I was a Gawker customer, which as you can now discover for yourself, I’m not, I’d be pretty unimpressed at the impact on my LinkedIn and Yahoo accounts.

Many people may not have cared too much that the account they use to leave comments on a media site was breached. But once the account they use as an essential part of their online identity – something potentially responsible for their reputation, job opportunities, relationships – became breached, well that’s a whole other story.

Here’s the sort of statement that worries me:

The information on our site isn’t that sensitive so security isn’t too important

I’ve seen this sentiment many, many times before and on the surface of it, it makes sense. Why bother investing in robust encryption, forcing strong passwords and implementing transport layer security when all you’re protecting is someone’s ability to comment on a news article? It’s not their bank account or anything, right?

Well, it could be. How many of those Gawker passwords do you think match up with passwords for accounts where people do care about security and they are protecting something valuable? Twitter, Facebook, Gmail, PayPal – any conceivable online service that requires no more than a username and password and let’s face it, that’s most of them.

Are you being a responsible developer?

Here’s an easy test:

1. Are passwords stored as a salted hash using secure cryptographic storage (“secure” is the operative word and it’s what Gawker didn’t do)? There should not be any facility to retrieve a plain text password from the system. And you should never be able to just browse through and read your users’ passwords.
2. Are there robust, minimum password requirements? None of the top 25 Gawker passwords would be classified as “robust”. Even just a reasonable minimum length and more than just one character type would exclude all but one of the top 25.
3. Is transport layer security such as SSL being used? Credentials (and arguably entire sessions in the wake of Firesheep), should not be transferred over unencrypted networks. It’s just too easy to get hold of them.

Of course web application security goes well beyond these three points alone but they’re usually the most frequently overlooked in the “my data isn’t sensitive argument”. They’re also very easy to implement, at least in the .NET world. The ASP.NET membership provider natively handles the first two and what’s an SSL certificate cost these days? Less than $70 a year from Instant SSL and a little bit of coding work? Many other popular products which include account management facilities are also cognisant of good password practices.

Particularly for the password strength test, you’re not only being a responsible developer, you’re providing your customers with a greater degree of protection from a Gawker style breach. Once again, almost none of those top 25 passwords would meet any reasonable definition of robust and would be useless on any site enforcing this standard.

I don’t buy the “barrier to entry argument” either; if the difference between someone signing up to your site and being an active user or walking away and never coming back literally comes down to something as simple as a few different character types, was this person really going to offer you any value? Yes, I know the likes of behemoths such as Facebook and Twitter are very liberal in this regard, but really, should they be? And doesn’t almost everyone have at least one account where the password isn’t a complete free for all?

The other issue to consider – and this is the totally selfish one – is that if one of your users had their account exposed in the Gawker attack and those credentials were then used – and exploited – in your site, who do you think the customer is going to blame? Gawker was high profile but the exact same thing is happening every day on a micro-scale without the sort of press that Gawker got. So who is your user going to point the finger at first when they find their account on your site has been compromised? And who’s going to have to deal with it?

Of course the password rule argument is a band-aid solution at best; people can still reuse strong passwords. The difference is that they’re far less prevalent and if they’re encrypted properly, they take a hell of a lot longer to crack. It’s a small but important step in the right direction.

What’s stopping you?

No, seriously, what is stopping you from meeting these three tests? Leave me some feedback – is it the effort in implementing? Is there a prohibitive cost factor? Are you concerned about performance? Is there really a usability factor?

Personally, I’ve protected myself by doing what we all know we should be doing; using strong, unique passwords on every site to ensure no single point of failure. But I, and quite likely you too, have a far greater role to play in ensuring basic, good security practice becomes pervasive. Because when you don’t do this, you not only jeopardise your own application, you jeopardise every other application your users frequent.

Your responsibility is not only to protect your application data, it’s also to protect your customers’ identities.