LastPass Security Breach?
Posted: Thu May 05, 2011 3:23 pm
(read the comments about all the people who can not change their password because of being locked out)
http://blog.lastpass.com/2011/05/lastpa ... ation.html
LastPass Security Notification
We noticed an issue yesterday and wanted to alert you to it. As a precaution, we're also forcing you to change your master password.
We take a close look at our logs and try to explain every anomaly we see. Tuesday morning we saw a network traffic anomaly for a few minutes from one of our non-critical machines. These happen occasionally, and we typically identify them as an employee or an automated script.
In this case, we couldn't find that root cause. After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server). Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed. We know roughly the amount of data transfered and that it's big enough to have transfered people's email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn't remotely enough to have pulled many users encrypted data blobs.
If you have a strong, non-dictionary based password or pass phrase, this shouldn't impact you - the potential threat here is brute forcing your master password using dictionary words, then going to LastPass with that password to get your data. Unfortunately not everyone picks a master password that's immune to brute forcing.
To counter that potential threat, we're going to force everyone to change their master passwords. Additionally, we're going to want an indication that you're you, by either ensuring that you're coming from an IP block you've used before or by validating your email address. The reason is that if an attacker had your master password through a brute force method, LastPass still wouldn't give access to this theoretical attacker because they wouldn't have access to your email account or your IP.
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're also taking this as an opportunity to roll out something we've been planning for a while: PBKDF2 using SHA-256 on the server with a 256-bit salt utilizing 100,000 rounds. We'll be rolling out a second implementation of it with the client too. In more basic terms, this further mitigates the risk if we ever see something suspicious like this in the future. As we continue to grow we'll continue to find ways to reduce how large a target we are.
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 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.
The LastPass Team.
UPDATE 1: We're overloaded handling support and the sheer load of password changes is slowing us down. We've implemented a way for you to verify your email and then not be immediately forced to change your password for that IP, access from any other IP would bring you back to email verification. You can now wait a few days if you know you'll be on the same IP without loss of security, and due to this overloading we think that's prudent to wait.
We're asking if you're not being asked to change your password then hold off -- we're protecting everyone.
You can access your data via LastPass in offline mode (pull the cable out of the wall then login) or by downloading https://lastpass.com/misc_download.php (choose your OS)
http://blog.lastpass.com/2011/05/lastpa ... ation.html
LastPass Security Notification
We noticed an issue yesterday and wanted to alert you to it. As a precaution, we're also forcing you to change your master password.
We take a close look at our logs and try to explain every anomaly we see. Tuesday morning we saw a network traffic anomaly for a few minutes from one of our non-critical machines. These happen occasionally, and we typically identify them as an employee or an automated script.
In this case, we couldn't find that root cause. After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server). Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed. We know roughly the amount of data transfered and that it's big enough to have transfered people's email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn't remotely enough to have pulled many users encrypted data blobs.
If you have a strong, non-dictionary based password or pass phrase, this shouldn't impact you - the potential threat here is brute forcing your master password using dictionary words, then going to LastPass with that password to get your data. Unfortunately not everyone picks a master password that's immune to brute forcing.
To counter that potential threat, we're going to force everyone to change their master passwords. Additionally, we're going to want an indication that you're you, by either ensuring that you're coming from an IP block you've used before or by validating your email address. The reason is that if an attacker had your master password through a brute force method, LastPass still wouldn't give access to this theoretical attacker because they wouldn't have access to your email account or your IP.
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're also taking this as an opportunity to roll out something we've been planning for a while: PBKDF2 using SHA-256 on the server with a 256-bit salt utilizing 100,000 rounds. We'll be rolling out a second implementation of it with the client too. In more basic terms, this further mitigates the risk if we ever see something suspicious like this in the future. As we continue to grow we'll continue to find ways to reduce how large a target we are.
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 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.
The LastPass Team.
UPDATE 1: We're overloaded handling support and the sheer load of password changes is slowing us down. We've implemented a way for you to verify your email and then not be immediately forced to change your password for that IP, access from any other IP would bring you back to email verification. You can now wait a few days if you know you'll be on the same IP without loss of security, and due to this overloading we think that's prudent to wait.
We're asking if you're not being asked to change your password then hold off -- we're protecting everyone.
You can access your data via LastPass in offline mode (pull the cable out of the wall then login) or by downloading https://lastpass.com/misc_download.php (choose your OS)