>Except among political junkies and sports fans, the kick-'em-when-they're-down impulse is stronger among techies than probably any community that doesn't engage in cannibalism.
When a major figure screws up, there's not much sympathy, especially when the screwup puts that company's partners or customers at risk – with poor security that fails to protect personal data for tens of thousands who trusted that a major technology company would handle its security responsibly.
That's not only a violation of trust, it's a violation caused by negligence, ineptitude or simply being too cheap to shell out for the necessary level of security.
So how should you handle a data breach in a way that will keep people from emptying metaphorical bedpans on your grave?
Check this customer-update online password-management service LastPass posted last night.
LastPass didn't take a major hit like Sony, Epsilon, Sony and Sony did. It found two anomalies in server logs that indicated someone might have gotten into a secondary database that held customer emails, encrypted passwords and, possibly, enough data to make it possible to crack the server's password.
Rather sit on the information for a week or two, as Sony did, LastPass pulled the server and database offline, unplugged the box on which they lived and is rebuilding it.
It also let customers know what was happening – in detail – and what it planned to do about it.
The data that might have been taken – there's no confirmation it was – wasn't a list of passwords or customer list sitting in the open. It was a set of encrypted data blobs that would give data thieves the ability to try brute-force attacks on those specific passwords, then come back to LastPass to get the rest.
Passwords that mix letters, numbers and/or other characters would be very difficult to crack; those that could be found in the dictionary would be simpler, but would still have to be attacked one by one – a far slower process than the wholesale-data-ingestion characteristic of most data breaches.
Even so, LastPass is forcing customers to change their master passwords and is upgrading its security to Password Key Based Derivation Function (PBKDF2) encryption using SHA-256 hashing, and accelerated rollout of a new client to support the tighter security.
The site is overloaded this morning with customers logging in to change passwords; they're also posting to the comments section under the announcement to complain about not being able to log in to change their passwords.
That's inconvenient, but less so than giving the master password for your secret-password file to strangers who think they can make better use of it than you have.
LastPass apologized for what it admitted might be an overreaction to an anomaly that is inconclusive evidence of a breach.
For any company to which customers trust private data – especially a security company such as LastPass – that's not an overreaction. It's the correct reaction.
And this is the right way to handle a potential threat to your customers.
For those of you who are curious: we don't have very much data indicating what potentially happened and what attack vector could have been used and are continuing to investigate it. We had our asterisk phone server more open to UDP than it needed to be which was an issue our auditing found but we couldn't find any indications on the box itself of tampering, the database didn't show any changes escalating anyone to premium or administrators, and none of the log files give us much to go on.
We realize this may be an overreaction and we apologize for the disruption this will cause, but we'd rather be paranoid and slightly inconvenience you than to be even more sorry later.
We don't have a lot that indicates an issue occurred but it's prudent to assume where there's smoke there could be fire. We're rebuilding the boxes in question and have shut down and moved services from them in the meantime. The source code running the website and plugins has been verified against our source code repositories, and we have further determined from offline snapshots and cryptographic hashes in the repository that there was no tampering with the repository itself.
Again, we apologize for the inconvenience caused and will continue to take every precaution in protecting user data.</blockquote>