As you have no doubt heard, LastPass has suffered yet another breach which makes at least 3 separate incidents this year alone. The latest incident appears to be a follow-up to the previous intrusion from back in August. Rather than recap the details of the breaches, this post will focus strictly on "how does this affect me/my organization" and "is LastPass still safe to use?"
Disclaimer - Recon is (as of this post) a LastPass customer. That said, we were already mid-migration away from LastPass prior to this latest incident, but our decision is only further solidified by recent events.
This is the first LastPass breach notification that clearly states that customer vaults have been stolen. Quoted directly from the breach notice:
The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.
But wait, surely LastPass factored this into their threat model and these vaults are useless in the hands of the attacker?
Well, yes and no.
These encrypted fields remain secured with 256-bit AES encryption and can only be decrypted with a unique encryption key derived from each user’s master password using our Zero Knowledge architecture. As a reminder, the master password is never known to LastPass and is not stored or maintained by LastPass.
What this is saying is that the vaults are safe, so long as your master password follows their best practices, is not easily guessed, crackable, reused elsewhere, etc. Unfortunately, that's a tough determination for the average user to make and unfortunately, best practices are not common behavior among the less technical of your user base. So how does one really know the risks of their vault now floating around in dark corners of the internet?
The largest risk to these vaults now is that an attacker has unlimited amounts of time to run offline brute force attacks against these vaults in hopes to crack open one more of them. What makes that even scarier is that opening even one vault could be detrimental to the organization it belongs to. Imagine how many passwords the average user has in a password manager, including not only their own accounts, but credentials and secrets shared between teams. (Note, I am not certain at this time how shared vaults are affected by this compromise, but assuming the worst.)
How would your users know if their password was "strong enough" to resist cracking attempts at these offline vaults? Sadly, even when attempting to follow passphrase best practices, users can easily make common mistakes like using a phrase from a book or movie, thinking that the length is sufficient for a secure password. Another common mistake is having an otherwise really strong password, but using it on another site which is subsequently breached and the password is revealed. There are many other possible circumstances that put a user's vault at risk of being cracked open anytime between now and years from now. While there is a lot of speculation circulating about the feasibility of password cracking against the stolen vaults, I feel it's impossible to know for sure just how many vaults may have been protected with easily cracked passwords, especially as cloud-hosted GPUs are more available now than ever. The only real limit here is time and money, something that, dare I say, APTs tend to have in spades.
Unfortunately, no. MFA only protects your access to the LastPass SaaS platform which stores your active vault. The attacker was able to copy backups of vaults which are only protected by the master password itself, rendering your MFA null and void in this situation.
Good, same here! But we are not out of the woods yet. Now that the only thing between the attacker and your vault contents is the master password, expect a never-ending onslaught of phishing and social engineering attacks against your users for the foreseeable future. Why? Because the value of the contents of those vaults is immeasurable. Prepare for some incredibly sophisticated credential harvesting campaigns over the next few months and possibly years.
However, there is a more immediate concern that requires no effort to exploit... Another eye-opening detail of this breach was that LastPass was apparently storing URL data for saved passwords in your vault in cleartext, and has for many years.
proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.
So who cares? They are just URLs, right? Ok, well let's think about the damage that could be done with just URLs. An attacker now knows every single account you have... This is the juiciest reconnaissance data a would-be attacker could have to help them focus on specific services of high value.
But wait, there's more...
Many of your IT, developers, engineers, etc., will also have countless internal resources stored in their vaults as well. Think things like internal-only systems used by technical folks to carry out their jobs. This is basically an invaluable map of your internal network without ever having to run a single scan.
So why on earth would LastPass choose to store these fields in cleartext? Potentially so that they could show you pretty logos next to your vault items. Not only does this undermine the security of the contents of your vault, but its a blatant departure from promises made by LastPass about their "zero knowledge security model":
Zero knowledge means that no one has access to your master password or the data stored in your vault, except you. Not even LastPass.
The bolded portion here is what I am calling into question... LastPass clearly has knowledge of specific data in your vault, at minimum, the URLs of your vault items.
I did some further testing on this concept and learned that not only are the URLs unencrypted in your vault, but they are also blasted across the web via HTTPS requests at the time you enter them into your vault, leaving them also possibly recorded in web server access logs and anywhere else LastPass sees fit to use this data.
The immediate damage reduction steps include auditing your users for those at highest risk, for instance, users that have reused their LastPass master password on other sites. You can look for some of these riskier users in the Admin Console under Security Reports.
Any users that are not confident that their passwords were aligned with "best practices" should consider their vault contents likely to be revealed at some point in the future and begin taking steps to mitigate the damage. Since it is unlikely that most vaults will be cracked open quickly or easily, there is still time to begin rotating credentials across critical applications over the coming days, weeks, and months.
Any critical secrets stored in LastPass vaults (domain or SaaS admin accounts, API keys, etc.) should likely be rotated for good measure over the coming days, weeks, and months.
Some universally good advice is to monitor breach databases like haveibeenpwned for not only your own accounts, but also all users of your organization via domain search. This at least provides additional visibility of where password reuse may cause problems in the future.
Sure. So long as you are currently, and have always used a very strong master password and never reused it anywhere else, you should be fine.
You'll also want to make sure that your "Password Iterations" setting is set to LastPass' recommended minimum of 100,100 rounds (which was not always the default), as some older accounts had a disturbingly low value of 500 or even 1 in some cases! This setting controls how many times your credentials are hashed using PBKDF2 before being sent to LastPass servers. So if you find that your account was set to a value much lower than 100,100 (as some are unfortunately learning to be the case), know that your vault is at higher risk than one with a higher iteration setting. It is worth noting that while LastPass recommends 100,100 iterations, OWASP recommends 310,000 as of 2021. Competitor 1Password only uses 100,000 (however, see below for mitigating factors) and Bitwarden uses 200,001.
Ultimately, just be sure you are aligned with everything mentioned in the latest incident report.
However, it is strictly my own opinion that orgs should consider migrating away from LastPass entirely. The application user experience is miserable in my opinion, but more importantly: their security design is flawed, their marketing is not truthful, and their track record for breaches this year alone is staggering. I have lost all faith in LastPass to adequately defend the sensitive information we depend on our password managers to protect.
Despite all of this, password managers are still a very necessary tool in the pursuit of a strong security posture and I disagree with the stance that all "cloud based" password managers are inherently insecure and/or all share the same flaws and weaknesses demonstrated by LastPass.
There are several options that I feel are superior to LastPass, my personal choice being 1Password. Not only is it a better app all around (UX/UI, features, etc.), but they have made wiser choices in how to secure your vault. Specifically, the fact that your password alone is not sufficient to decrypt the vault contents, but you would also have to have the "Secret key" which is only stored on your authorized devices. This means that even if 1Password suffered the exact same breach, the vaults would be virtually worthless to the attacker because they would need not only your (possibly guessable) password, but also a 128-bit key that even you don't know, which makes it practically impossible for them to obtain it without maybe stealing one of your devices. While 1Password doesn't advertise it this way, this feature effectively provides an MFA component to your raw vault contents as you need something you know (your password) and something you have (vault secret key stored on your existing authorized device) in order to decrypt the contents. Read more about it in their Security Design white paper.
Another honorable mention, but one I do not have personal experience with, is Bitwarden. This solution appeals to many because it is open-source and has a self-hosting option.
References