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
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.
