LastPass shows how to handle potential data breach

Tell customers, change passwords, rebuild the box, upgrade security. Listen up, Sony.

By  

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.

More information from LastPass:

<blockquote>

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.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Ask a Question
randomness