Let me set the scene for this post by sharing a simple tweet from last night:

Ok then, that’s about as many security misdemeanours as I reckon you can fit in 140 chars! For those wondering, yes, this is actually a verified account and it really is Tesco responding to me. I’ll come back to Tesco’s many interesting views on security a little later, but first, some background:

I keep a watch on mentions of my blog over on Twitter and get a lot of tweets along these lines:

Curious, as always, I headed over to tesco.com to take a look. A few cursory glances around showed perhaps there was a bit of an opportunity here – an education opportunity for developers who like to learn from anti-patterns, i.e. seeing how those who have gone before them have done it wrong. So let’s take a look at the many simple security errors Tesco have delivered and see how we would approach this differently when applying basic security principles.

Oh – and for audiences outside the UK, Tesco is a major supermarket chain the likes of Coles in Australia or Costco Safeway in the US. You know, the kind of multi-billion dollar brand that should know how to get web security basics right, particularly when they’re providing online shopping services and handling your payment info. They also provide banking and insurance services, although that’s not an area I’ll look at in this post.

Last month I wrote about our password hashing having no clothes which, to cut to the chase, demonstrated how salted SHA hashes (such as created by the ASP.NET membership provider), offered next to no protection from brute force attacks. I’m going to assume you’re familiar with the background story on this (read that article before this one if not), but the bottom line was that cryptographic hashing of passwords needs to be way slower. Not half the speed or even one tenth of the speed, it needs to be thousands of times slower.

The conclusion of the post was frankly, a little unsatisfying. Why? Because it essentially said “If you take my favourite technology stack and use the default implementation to store passwords, it’s insecure”. Yes, I suggested alternative approaches but these didn’t work natively with the membership provider or required machine.config access so they really weren’t conducive to today’s world of getting an app up into the cloud in 5 minutes.

But it turns out that we’re on the cusp of solving this for ASP.NET and you can access a better solution right now. In fact you may even be using it already and just don’t know it because until now, it really hasn’t been publicised.

It happened again last week. No, not Yahoo! Voices, not the Phandroid Android forums, not NVidia and not Formspring, this time it was Billabong, our legendry Aussie surf brand. As is often the way with these breaches, credit was quickly claimed via Twitter:

Unfortunately there’s now a nice dump of over 21,000 email addresses and passwords freely available for the world to peruse at their leisure. (The apology in the tweet was due to previously claiming credit for a breach which ended up having been stolen by someone else. Turns out that anonymous hackers can’t be trusted.)

So what went wrong? How does such a thing happen? It’s not quite clear yet, certainly nothing has been publicly said about root causes, but I propose that in a case like Billabong, the writing was already on the wall. In fact the signs are still all over their websites, you just need to know where to look.

Another week, another breach. This time Yahoo! was the target with 453,491 email addresses and passwords from their Voices service being exposed for all to see. Whilst unfortunate for those involved, these breaches do give us some unique insight into password practices and as is usually the case, it’s not pretty.

Back in June last year after one of many Sony breaches I conducted a brief analysis and found a litany of bad password practices. Less than 1% of passwords contained a non-alphanumeric character, only 4% actually used more than two character types and 93% of passwords were between 6 and 10 characters long.

What made the Sony analysis particularly easy (and relevant) was that there was no cryptographic storage – everything was in the clear. You’d think that by now the big guys would have worked out that storing passwords in the clear is not on, I mean just look at the bad press LinkedIn got last month and they at least made a small attempt to hash them. Whilst the details are still sketchy, the early evidence is that Yahoo! kept their passwords in the clear and certainly the dump appears to support this with quite a number of “strong” passwords appearing in the breach and unlikely to have been brute forced, at least not without a very comprehensive dictionary.

I thought it would be interesting to take a quick look at what’s in this breach and the metric I was specifically interested in was prevalence of password reuse with the Sony breach: