LastPass, a company that offers users a way to centrally manage all of their passwords online with a single master password, disclosed Monday that intruders had broken into its databases and made off with user email addresses and password reminders, among other data.
In an alert posted to its blog, LastPass said the company has found no evidence that its encrypted user vault data was taken, nor that LastPass user accounts were accessed.
“The investigation has shown, however, that LastPass account email addresses, password reminders, server per user salts, and authentication hashes were compromised,” the company said. “We are confident that our encryption measures are sufficient to protect the vast majority of users. LastPass strengthens the authentication hash with a random salt and 100,000 rounds of server-side PBKDF2-SHA256, in addition to the rounds performed client-side. This additional strengthening makes it difficult to attack the stolen hashes with any significant speed.”
Parsing LastPass’s statement requires a basic understanding of the way that passwords are generally stored. Passwords are “hashed” by taking the plain text password and running it against a theoretically one-way mathematical algorithm that turns the user’s password into a string of gibberish numbers and letters that is supposed to be challenging to reverse.
The weakness of this approach is that hashes by themselves are static, meaning that the password “123456,” for example, will always compute to the same password hash. To make matters worse, there are plenty of tools capable of very rapidly mapping these hashes to common dictionary words, names and phrases, which essentially negates the effectiveness of hashing. These days, computer hardware has gotten so cheap that attackers can easily and very cheaply build machines capable of computing tens of millions of possible password hashes per second for each corresponding username or email address.
But by adding a unique element, or “salt,” to each user password, database administrators can massively complicate things for attackers who may have stolen the user database and rely upon automated tools to crack user passwords.
“What a salt does it makes it hard to go after a lot of passwords at once as opposed to one users’ password, because every user requires a separate guess and that separate guess is going to take a considerable amount of time,” said Steve Bellovin, a professor in computer science at Columbia University . “With a salt, even if a bunch of users have the same password, like ‘123456,’ everyone would have a different hash.”
More concerning in this particular breach, Bellovin said, is that users’ password reminders also were stolen.
“I suspect that for a significant number of people, the password reminder — in addition to the user’s email address — is going to be useful for an attacker,” he said. “But password reminders are useful for targeted attacks, not massive attacks. That means that if your password reminder or hint is not particularly revealing to someone who doesn’t know you, it probably doesn’t matter much. Except in the case of targeted phishing attacks,” which might try to leverage data known about a specific target (such as a password hint) to trick the user into giving up the answer to their password reminder.
So what’s the takeaway here? If you entrust all of your passwords to LastPass, now would be a terrific time to change your master password.
QUOTE >> “LastPass said the company has found no evidence that its encrypted user vault data was taken, nor that LastPass user accounts were accessed.”
Answer:
…absence of evidence
is NOT
evidence of absence…
then what would evidence of absence look like?
I think you aren’t understanding what you are replying to. It’s basic logic, to be honest.
Never heard of a copy command? It doesn’t move the data, just copies the data needed. It sets a temporary space, copies the data, moves the copy to where you tell it, and then eliminates the temp copy space. It works that way all the way down to assembly/machine language. It works that way unless it is copy protected, and its so easy to change the read bit…to allow.
Evidence of Absence: These are not the logfiles you’re looking for…
Yep … my first thought was of all the other hacked companies that made the same public statement and then later on changed their tune.
Hmmmm…might be a good time to get a job in the booming industry of credit protection (at whatever level it may be!) …
If you have a good master password, and the encryption is high-grade, it doesn’t matter if a hacker steals your password database, that’s the point!
I.e. you don’t rely on the fact your passwords cannot be stolen. They will. But you rely on the fact that once stolen, they cannot be read.
Lastpass has a heavily instrumented internal network. When they say “we have found no evidence that encrypted user vault data was taken,” that is a meaningful statement. It is not simply an absence of evidence–it is evidence that the data was not stolen. Another way to think of it: the bad guys left footprints, and those footprints did not lead to the user vault. Now, you could argue that the entire system was compromised, including the intrusion detection, and the bad guys decided to leave some data around as a red herring, but that’s pretty far-fetched.
I turned on two-factor authentication a long time ago, so while I changed my master password, I really wasn’t that concerned about this.
Overall I think lastpass does a good job. We all need to start looking on single factor authentication as badly broken and assume your password is already compromised. Two-factor for anything important is kind of a minimum when it’s available these days.
I also never put financial institution passwords in an internet based password manager and remember the bank ones from memory, but this is just simple common sense.
I agree about two-factor authentication. I’ve had that turned on for years and I know I’m much safer for it.
But I think the “important passwords” is where a password manager is most needed.
How else could you have something like uQ$ZA4X21g9t as your password? And have it different for every site? And easily change it as often as you like? And never be afraid of forgetting it?!
Yes, you need to be careful (and read Krebs daily), but the alternative is way more risky in my “common sense”.
Keep in mind that 2-factor only protects against unauthorized access of the LP infrastructure (website etc). In case your vault is stolen and they are able to crack your master password, the 2-factor will not help you.
AFAIK, your vault is not encrypted with the 2nd factor. At least, I cannot reason how they would do this, as the 2nd factor is a changing number.
LP claims that there is no evidence that the vaults have been copied. (but a very good hacker is able to remove his traces…right? ), so you (and me) will be ok….
+1
So many lastpass users (of which I am one for my low to medium security passwords) do not understand this. And lastpass marketing doesn’t really do a lot to clear this up. The only protection on your encrypted password list is your passphrase. The second factor just controls whether lastpass gives you the encrypted list.
If the attackers get your encrypted list (which it doesn’t look like they did in this case), then the second factor provides zero extra protection.
If the atacker did manage to get the vault it does not really matter if you change the master password since he has the (salted/hashed) password for the copy of the vault he obtained.
That’s true, but I’m not sure how it’s relevant to the discussion about 2FA.
Except Brian doesn’t post something every day, or I would.
debian, kali linux and subterfuge attack framework are my best tools
Nothing is infallible.
So this is their 2nd breach in 3 years….the perps got off with e-mail addresses and password reminders and encrypted data of the really important stuff that they’ll work on.
Seems like this (cloud based password managing service / honeypot) might not be a good way to attack the problem.
The vociferous defense of the company by its users is interesting to see….like there is so much emotional investment there that there is just nothing else they’d consider using. Makes one wonder what it’d take for those folks to look for another solution?
There’s something about the word “cloud” that really endears itself to a lot of people, to the point that rational discussions about the security consequences of placing their data on someone else’s server that’s 24/7 internet accessible, with no account lockouts for incorrect passwords, not to mention depending on them to maintain adequate security, and a whole host of other problems inherent in the model… just simply becomes impossible. It’s cloud or bust and stop trying to poke holes in my cloud.
Similar discussions happen with young computer users, who expect everything to be free and don’t see the problem inherent in downloading software from random internet sites and running them with administrative credentials, because why would anyone ever put something malicious in their “free” software…
i wonder too…
i use RoboForm but have grown disillusioned with what seems to be their utter refusal to embrace some of the various third-party options that everyone else has. It’s as though they’re convinced it’ll never happen to them.
I’ll give LastPass credit — I think it’s the way they’ve handled this & the previous breach, along with the way they put out there how they do things, that has kept their subscribers loyal. If they tried to cover it up and it got out, it would be game over.
If I get mugged or my house/business is burglarized, the computers and phones will be the first things taken.
Do I feel confident that my own ability to keep stored passwords burglar-ready on my own machine at all times is comparable to the skills of the experts who design the password-vault services like LastPass? Oh, hell, no.
If your entire plan for safety depends on keeping people from getting access to your data, you’re not very safe. You’re storing data that is attractive to thieves on hardware that is attractive to thieves. They will get at your data from time to time, guaranteed. All you can hope for is layers of security to make sure a single point of failure won’t be game-over.
On both break-ins lastpass has been very forthcoming with information. Both times, the break-ins were detected via lastpass’ internal security measure–not, as is so often the case, by external observers seeing that the site has been broken into.
Given that they are the preeminent password vault, they will be the subject of persistent attack by skilled adversaries. I do not expect them (or anybody else) to be impervious to all attacks, so I value the fact that they publicize when it does happen and take active steps to correct it. And that they have layered defense that have (to date, including this latest attack) kept my data safe.
A heavily-used password vault that never reports a break-in is a password vault that isn’t looking for break-ins.
I changed my passwords and I am staying with lastpass. There is no way i can manage all my passwords myself especially those that are 100 characters long on dozens of sites. And i’m not even talking about the junk sites I always use the same simple passwd on cause I don’t care if they get compromised.
To store the passwds on my computer would be a huge pain and will suck when my own box gets compromised or when the hdd dies, or when i have to log into a site from multiple devices….
Passwords are obsolete and I don’t have a smartphone (which to me is more vulnerable then anything) So we need another way to authenticate. Two factor, even with mutliple devices, is not the answer imo. Look at heartbleed.
From what I have read: LastPass stores its password representations using the following-they are salted, hashed and stretched, and only ever stored in that scrambled, irreversible form.
———-
“…server per user salts, and authentication hashes were compromised”
“LastPass strengthens the authentication hash with a random salt and 100,000 rounds of server-side PBKDF2-SHA256, in addition to the rounds performed client-side.”
———-
So, in this case, IF the ‘encrypted user vault data’ also were stolen with the ‘server per user salts and authentication hashes’, would it be theoritically possible to derive the passwords using a rainbow table or any other method?
(I am trying to figure out how the layers of ‘random salt and 100,000 rounds of server-side PBKDF2-SHA256, in addition to the rounds performed client-side’ are securing the passwords)
Once you see salting involved, you can rule out rainbow tables as an attack.
With any decent password hashing scheme, the only way to “crack” it is to try a password, hash it, and see if the result is the same. That attack is always possible if you get a hash of the password, and it can’t be prevented. What they can do, is to slow it down. There are 2 things that can be done to slow it down.
By salting it, the attackers cannot use pre-computed lists of hashes, as there are too many salts, and they would need a different list for each possible salt (which is infeasible with current storage technology).
The other is to store the hash of the hash of the hash of the hash … (you get the idea). Lastpass run this 100000 times. This makes cracking passwords 100000 times slower than the naive approach of running it through the hash once. It also makes checking the password 100000 times slower, but that is not a huge burden in practice.
As for “in addition to the rounds performed client-side”, I don’t know for sure, but I suspect they hash it a few times client side, then send it to the server, which hashes it another 100000 times. As for how many, they aren’t saying. It could be anywhere from 1 time (2 if you take the pluralisation of rounds) to many thousands. This increases the difficulty factor for the attacker from 100000 to at least 100001.
Hi Matt,
Thank you very much for the clarifications.
If I rephrase my query a bit more:
Even when the salting is involved, IF the attacker gets hold of the ‘hashed passwords + the server per user salts and authentication hashes’, does it mean the passwords could be cracked? Or, would the stolen passsords be still safe/unusable strictly because of the ‘client side hashing’ piece of information is still not with the attacker?
And, what (and how) are the possibilities the client side hashes also being compromised? Could client side hashing be compromised at the individual client end or at the server end?
How does the client application (browser) decide the criteria to hash the password (to or not to do client side hashing, or how to simply create the password hash) before sending it to the server for authentication?
If you feel that this discussion is on a different track now, I have to admit that I am trying to understand what happens in a typical web application user authentication scenario (when client side hashing is used and when it is not used) where a the password hash is sent from the client to the server, for the server to compare it with the stored hashed password. Hope you/someone else would clarify this for me.
If the attacker gets hold of the salt and the hash (which they did in this case), then they can crack the password by trying words from a list and seeing if they match. Client side hashing does not change the overall approach the attacker has to take, it only adds more rounds to the hashing process. The more rounds there are, the longer it takes to test a potential password, and the slower the cracking will be. So yes it is theoretically possible, but whether your password gets compromised depends on whether the crackers can guess it before they give up.
If the attacker has compromised the client, then they would simply capture the password as the user enters it.
In the case of Lastpass, there is an account setting for the number of client side hash iterations to use, defaulting to 5000. I’m guessing the server tells the client how many iterations to use after the user provides their username.
Lastpass is very atypical in how it handles this. For a typical website, the password is sent unhashed to the server, then the server hashes it (after combining it with the salt for that user) and compares it to the stored hash in the database. Some badly written sites store the password in the clear or don’t use salting. Better sites use multiple iterations of a hash to slow down the process. This is the only site I know of that uses client side hashing as an additional step.
Thanks a lot.
Would you also elaborate on (when we use PBKDF2/ bcrypt/ scrypt) what type of practices (in development and in operation as well) are recommended to take the best care of the per user salts and per user/sytem hashing iterations settings?.
This, is to implement the ‘best of the password authentication’ before looking at 2FA, SQRL etc.
Regarding LastPass and 2 Factor Authentication.
Isn’t 2FA as it pertains to LP something that only applies to the front-end LP interface? If attackers managed to obtain the encrypted LP vaults (which apparently didn’t happen here) how would 2FA help? They could still attempt to decrypt the vaults via brute-force, right?
I do realize that this current incident involves a different scenario: LP hashed master passwords stolen, which if broken would reveal the master password and enable the crooks to login to LP – in this case 2FA would likely be effective.
Totally agree.. Surely enabling 2fA would do nothing to stop the data from being exposed if they had gained access to the encrypted “vault”. But in the current situation, enabling 2fA surely has helped.
I agree with the comments that multi-factor authentication is a good way to protect yourself where it is currently available. I’d like to see investment in alternative authentication technologies as well. In particular, I recommend taking a look at Steve Gibson’s SQRL: https://www.grc.com/sqrl/sqrl.htm It could co-exist with a username/password system already in place by a given website; supporting SQRL wouldn’t require a site’s users to all switch to it right away.
A manager that you control more thoroughly, like KeePass on your desktop etc. is worth considering.
If anyone’s interested, recently wrote a piece on the nuts and bolts of hashing passwords at http://www.simple-talk.com/dotnet/development/safe(r)-custom-user-authentication/
Extremely informative and well-written post. Please keep them coming!
So far, as a family using all Apple gear, we have been quite happy with the built-in password manager iCloud Keychain.
It didn’t always auto fill or capture newly created passwords when it first launched, but it seems to have that under control now. Biggest remaining shortcoming, for me, is the lack of a menu for choosing different authentication credentials for the same domain (workaround is to do a copy paste of the password from the desired authentication key in the keychain to the site being logged into).
Apple also announced last week at WWDC that they would be adding 2FA to iCloud, but I am not sure in what form they will do this (it was added last year as an option for logging into the Apple ID management page.)
By setting up all our devices to use this system, we take advantage of a password generator, capture of new/changed passwords, auto filling of authentication credentials, unique passwords for each site we visit, and syncing across all our Apple devices. Nobody has weak, overused, or forgotten passwords in our family any more (plus we manage and use our credit cards within it as well.)
In order to have reasonable security that is manageable by a normal person today, anybody using their gear for anything remotely important will need a pw manager. Some might find that they need more sophisticated managers than the iCloud Keychain but for something that is free, easy and likely sufficient for average users, it can’t be beat.
Read this and see if you still feel as good about your Apple decision. http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/
And Brian has posted yesterday on this subject as well.
I seriously believe that there will be shortcomings with every possible solution available to a user. I know many people have complete confidence in Apple products, mainly due to the myth that they can’t be infected with viruses. I suspect they extend that to believing they can’t be hacked either – but there is always a first time, especially if one becomes too complacent in their sense of security.
But I feel that the opposite can also lead to danger – hyper-paranoia. I’ve seen plenty of evidence of this throughout the discussion about LastPass here.
Really, the ONLY way to ensure 100% effective safety from being hacked, getting sensitive info breached, etc is to completely isolate yourself from the internet. Good luck with that! With great irony, I note that even that can’t guarantee total safety in this time where everything and everyone is connected via internet (I now have to pay my rent online – no checks accepted!). If you isolate yourself from this, you lose experience and practice, making you more vulnerable.
And so, we evolve!
How can emails stored on some third party servers be secure? Binfer is a great way to send secure email. It does not store emails anywhere so is very secure. Visit http://www.binfer.com for details.
Deleted all my passwords from LastPass, then purged them (apparently deleting doesn’t remove them from LastPass system). Changed master password to extremely long random generated string, then deleted my account.
No more online password management for me….this inability to prevent data breaches is what made me wary to store passwords online to begin with – can I really trust their data encryption if I can’t trust their network security.
Sticking with KeePass.
They are not positive data was stolen, but they believe one of their workstations might of been compromised due to strange traffic when noone was working and are taking no chances.
Not only that, if you changed your password your fine. One of the main reasons I use lastpass is to quickly log on to accounts from different devices from anywhere at anytime.
Steve Gibson suggested to go to the advanced lastpass options and restrict access by country and up the password iterations for some extra security to at least 5 digits, first number higher then 2, and no 0s.
Now that’s what I call an overreaction! Either that, or an underhanded way of trying to advertise KeePass.
Use a local storage on your computer. Plenty of software you can use.
A small “passwords” notebook could be considered even better. At least it can be accessed more quickly and easily, especially from multiple locations (as long as you remember to carry it with you everwhere) and isn’t subject to loss from hard drive failure or computer theft.
Then again, unless regular copies are made, if you lose it, you’re hosed. And if it falls into the wrong hands… you’re hosed!
NO system will be perfect. Or perfectly safe.
well, now that the Chinese know your email associated with your LP account, the question is, presuming your not using LP for that email, as it is your recovery email.
is your recovery email password adequately random, or is it < 13 characters and something you can remember, as the LP pw recovery process is probably a weakest link……
While that may give you the LP account, it can’t decrypt your vault.
Hey Brian, Could you take a look into PasswordBox? Seems like something similar to Last Pass. Just curious on if it’s any better or if they had any issues that we should be aware of.
Given this, is 1Password (synced via Dropbox) a more secure alternative to Lastpass? Local-only options (non-synced 1Password) or KeePass just aren’t useful enough to make the tradeoff for me.
It occurred to me, there are going to be a few people who die between the time they change their master password and the time they get around to updating it in their safe-deposit boxes or whatever other method they use for storing it for their heirs. And their families are going to have some headaches.