LastPass云端帐密管理服务疑似遭入侵，建议用户更换主密码
原文出处：http://playpcesor.blogspot.com/2011/05/lastpass.html，转载请注明原始出处。
来自LastPass官方博客的消息，美国时间星期二时LastPass侦测到其部分服务器有可疑的流量，从最谨慎的判断来看，他们认为不能排除黑客入侵的可能性，而最糟的情况就是部分用户帐号（电子邮件位址）遭到流出。LastPass官方的解说是，如果你在LasPass主密码上使用的是具有一定强度的密码，那么应该还不用太担心自己的帐密资料库被破解，但反之则可能就有比较大的风险。
无论如何，虽然仍在调查可疑流量的阶段，但LastPass决定拉高防范的层级，接下来LastPass会强制用户更换“主密码”，并且在更换时，会确认用户的IP（你必须使用之前用过的IP区段）或Email所有权，以确保你就是你本人。
更详细的LastPass说明，请参考官方文章：LastPass Security Notification，而对于安全技术的解说就留待其他高手的说明。总之现在对于LastPass用户来说，就像LastPass提醒大家的：赶快去更换你的LastPass主密码，并且尽量使用复杂一点、非单字词汇的密码。如果希望使用工具生成具有一定强度的密码，可以参考我以前的文章：随机生成高强度密码的7个网站服务，按照我平常的使用习惯，建议生成20位以上的高强度密码。
以下是LastPass的官方说明文章，转载如下：
LastPass Security Notification
Update 5, ~1:30am 05/06 EST:
We've added the option for you to say that you know your master password is strong and to avoid password change, we apologize for not having that available when we announced.
We've identified an issue with roughly .5% of users that impacted their master password change, and will be contacting you tomorrow rolling you back to before the change.
Our focus right now is on ensuring we can resolve users with issues, we'll continue to provide updates here.
Update 4, ~10pm EST:
Joe's interview with PCWorld covers more details on what happened, what our thought process has been, and what this means for our users: http://www.pcworld.com/article/227268/exclusive_lastpass_ceo_explains_possible_hack.html.
We continue to work as quickly as possible to address user support.
Update 3, ~4:30pm EST:
Logging in offline should be working everywhere if you have logged in using that client before, if you're having problems with this please attempt to login via the website: https://lastpass.com/?ac=1 that should now take you through an email process to enable your current IP.
If you're having problems getting your data with pocket, make sure you're selecting to login to the local file, not logging in at LastPass.com.
If you changed your password and are now having problems we'll help with that too, please email us if that's the case and include your LastPass email address.
For those who haven't been prompted, and have continued to use LastPass without issue -- we've judged the risk to be low if you're using the same IP -- we're only raising the issue once that changes.
Finally if you have issues with password changes please email us at support@lastpass.com, we can revert you, or we can pull data from backups, but please try LastPass Icon -> Clear local cache first.
Update 2, 2:15pm EST:
Record traffic, plus a rush of people to make password changes is more than we can currently handle.
We're switching tactics -- if you've made the password change already we'll handle you normally.
If you haven't the vast majority of you will be logged in using 'offline' mode so you can still use LastPass like normal and get back to your day, only syncing of new password should suffer (and you'll see the bar).
As load lowers we'll increase the percentage of people being sent through email validation / password changing.
For people experience problems please email us at support@lastpass.com -- we have seen a few reports of bogus data post change, we think this is due to you downloading a stale copy and if you go to LastPass Icon -> Clear Local Cache and try again it should work.
You can access your data via LastPass in offline mode or by downloading LastPass Pocket : https://lastpass.com/misc_download.php (choose your OS).
---
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.