Lessons you can learn from the LinkedIn LeakOut

Last month, millions of LinkedIn members discovered their passwords had been published by hackers. But what can your enterprise learn about security, and how to deal with a breach situation, from this unfortunate incident? Davey Winder investigates...

Dealing with disaster

All businesses want to mitigate potential brand damage that a hacking incident can cause. Damage limitation should start as soon as possible by confirming that customer personal and financial data has not been exposed. I'm not convinced LinkedIn pulled this off after they suffered a breach. Disclosure has to be timely, complete (within regulatory compliance boundaries for your industry) and accurate if it is to truly mitigate damage. Most importantly, it has to be perceived as being a genuine explanation and not merely a marketing exercise if your customers and business partners are to be satisfied.

LinkedIn director Vicente Silveira has gone on the record to state:

1. The compromised passwords were not published with any corresponding email logins

Advertisement - Article continues below
Advertisement - Article continues below

2. The majority of the passwords when published were in hashed form

3. There appears not to be any LinkedIn member information that has been published anywhere as a result of the stolen password list appearing online

So what do I mean by 'perceived as genuine' and why doesn't this cut the mustard in my opinion? Well, even if it were not your intention, a statement that could easily be interpreted as simply papering over the cracks will do more damage than no statement at all. Just because a list of passwords was published without their corresponding logins does not mean those logins were not also obtained. If you KNOW that logins were not stolen then say so; if you don't yet know then make your position clear. Similarly, a few days after the incident was uncovered, don't bother making a big deal that no associated personal data has been published online because, frankly, that means nothing. By all means state categorically that none was compromised if you know that to be a fact, but stating that the worse hasn't happened yet (which is, in effect, all this actually says) is not a good strategy for putting customers minds at rest.

Rubbing salt on the wound

I have, however, saved the biggest problem for last and that's the statement regarding password hashes. Much was made within hours of the leak being uncovered concerning the fact that apparently the LinkedIn password database system only hashed and didn't also salt the member passwords. This statement was the perfect opportunity, a few days later, to put the record straight and apologise for a pretty basic lapse in security thinking.

Admittedly LinkedIn did say that it was moving member passwords from a hashed database to one that was hashed and salted, but no explanation was made as to why this wasn't there from the get go. As one web developer told me "salting passwords was in my PHP development 101 class at college" so how come a system with the resources (in terms of manpower, knowledge and finance) happened to think it not worth bothering with for a system of this size? Actually, scrap that last comment and replace it with 'for a system of ANY size'. Protecting passwords with a solitary single layer of defence, a SHA-1 hash, is akin to using an intruder alarm from the pound shop to guard your office instead of a state of the art system backed up by on-premises patrols with dogs.

Featured Resources

2,000 days: the CIO's world in 2025

What the role of the CIO will look like in five years time

Download now

The workers' experience report

How technology can spark motivation, enhance productivity and strengthen security

Download now

6 best practices for escaping ransomware

A complete guide to tackling ransomware attacks

Download now

The IT roadmap from modernisation to innovation with consistent hybrid cloud

A guide to a modern, cloud-enabled IT infrastructure

Download now

Most Popular

data governance

Brexit security talks under threat after UK accused of illegally copying Schengen data

10 Jan 2020
cyber security

If not passwords then what?

8 Jan 2020
Policy & legislation

GDPR and Brexit: How will one affect the other?

9 Jan 2020
web browser

What is HTTP error 503 and how do you fix it?

7 Jan 2020