LastPass Breach - What went wrong?

Written by Guy Barnhart-Magen and Sharon Brizinov

disclaimer: this is based on our experience, expertise, and public sources

Feb 28th update

Some Background Link to heading

Why should you listen to us? Link to heading

Guy Barnhart-Magen Link to heading

Around 2015, Guy found himself designing the architecture and security for a high-performance HSM Hardware Security Module (a high-security password manager), and a bit later (around 2019), designing the algorithms for a new type of password manager based on a new approach (which was patented).

Guy spent a great deal of time balancing the needs of the product with the security needs of protecting those secrets and is acutely aware of the various pressures involved.

Sharon Brizinov Link to heading

Director of Security research @ Claroty (linkedin)

What is a password manager? Link to heading

A password manager is a place to store your passwords more securely than using a post-it on your computer screen. Password managers became prominent when security people educated the public about password reuse.

Password reuse was a big issue a couple of years ago, as a breach in a single service would allow attackers to use the same password from that breach on other sites, hoping that the user “reused” his password. As the need for more passwords and remembering them became greater, systems to manage many passwords were needed - and thus, password managers were born.

We encounter password managers in different aspects throughout our day. For example, some of us use the built-in password manager of the browser, while some use dedicated software like LastPass or 1Password.

As the need for additional security grew, MFA authentication was added, and these were also kept inside password managers or mobile-based applications (we can recommend authy), which are password managers themselves.

Keeping all these passwords synced between devices, secure, and providing a simple user interface (UI) to use - is a delicate balancing act and a place where we often find failures.


What do we want from a password manager? Link to heading

Any password manager should be able to provide the following basic features:

  • store our passwords in a secure way
  • provide me with a friendly UI so we can get our passwords when we need them
  • make an effort to find the correct password minimal

While for security people, the security of the product and keeping their passwords and secrets are the most important aspect, for most users, providing a friendly, usable UI is often more critical.

It is possible to balance the two, but we also think that LastPass made some bad product decisions down the line, which are the main problems behind its current issues.

one password to rule them all

How to store passwords securely? Link to heading

To store your passwords securely on your devices or in the cloud, you want to ensure that only the owner can access the passwords. That means we must encrypt them with a key known only to the owner.

Ideally, we would want each service or website we use to have its unique secrets, with a single password known only to the owner to access them all.

So the question now is how do we protect the user’s secret key, or as it is commonly referred to, the master password?

We make some assumptions regarding that master password:

  • it should be a very strong password, as it protects all other passwords
  • it should never be reused, as it will weaken its strength
  • it should be challenging for an attacker to guess/break

Unfortunately, these assumptions don’t always hold in the real world. For example, the best possible password would be a sufficiently long (12 characters minimum) randomly selected password. But most people use words or phrases that they find easy to remember, which creates a significantly weaker password.

So, What happened at LastPass? Link to heading

LastPass disclosed that they had a breach on August 2022 of their cloud storage. That storage held backups of the customers’ encrypted vaults.

They also claimed that customers were safe if they kept to the default settings (which they provided):

  • since 2018, they have had a 12-character password minimum
  • they use “stronger than typical” PKDF2 with 100,100 iterations
  • they recommend never reusing the master password anywhere else

They also claimed that customers were safe as LastPass employs a “zero knowledge” architecture.

So - this means the attackers have nothing. Furthermore, the customer’s vaults were encrypted with the master password, so all should be OK.

Reality Check Link to heading

PKDF2 Link to heading

Password Key Derivation Function (PKDF) is an algorithm that allows us to take an input and compute an output so that having a production will not let you derive or guess the information.

For example, if you want to compare the user’s master password with the master password on the backend or service side, it would be best if the back had “Zero-knowledge” of the actual password. This is because when using a PKDF, the backend stores the result of the computation and is unaware of the existing password.

You would also want this function to be computationally expensive. For example, if you use some easy algorithm to compute, an attack can calculate all results for common passwords and get the master password that way. Pre-computing these results and preparing them for use is often referred to as a hash table.

The computational intensity of the PKDF2 function is determined by its parameters, and here we usually consider the number of iterations. as the number of iterations grows, every single computation takes longer. It makes it much harder to pre-compute a hash table.

Until 2018, LastPass required 5,000 iterations for the PKDF2 implementation, and since then upgraded to 100,100 iterations. However, it should be noted that while 100,100 is more extensive than 100,000, it would hardly qualify as a “better than typical” implementation as the best practice today is around 300,000 iterations.

Users with accounts before 2018 still use 5,000 iterations


Key derivation using PBKDF2-SHA256 with 100,100 iterations is slow (as intended). On a Macbook Pro laptop with Python, we reached ~10 derivations per second. Of course, this is far from being optimized (CPU vs. an array of GPUs, Python vs. ASM, crypto code optimizations, etc.). Still, even if we increase in multiple orders of magnitude (~0.1m/1m/10m), it will still be slow enough never to be able to brute force the 12 chars master password.


So to be able to crack the passwords (LastPass recommends at least 12 chars with multiple symbols), the attackers would need to reach a brute speed of ~100,000,000,000,000 PBKDF2-SHA256 with 100,100 iterations per second. Good luck with that.


Everything is protected! Link to heading

Well, except metadata such as URLs and other information. Unfortunately, this means attackers with a user’s vault have access to the list of services you’re using - which could be better.

Consider the following scenario. A phishing email crafted by an attacker goes something like this:

Dear user of <SERVICE>,

As LastPass was recently breached, we recommend resetting your password at <PHISH_URL>.

Technical Details Link to heading

We wanted to see exactly what data is encrypted and what’s not, so we opened a new LastPass account and filled it with fake accounts. Then, we got the vault (stored locally and transferred via getaccts.php). Then, we parsed it using lastpass-vault-parser and saw which specific fields were kept - encrypted and unencrypted.


We discovered that the following fields are encrypted using an AES-256-CBC key derived from PBKDF2 with 100,100 iterations of the Master Password (each encrypted field has the structure of !base64(IV)|base64(AES-256-CBC):

  • Item Name
  • Folder Name
  • Notes (secure and not secure)
  • Username
  • Password

It’s important to notice that bank accounts and credit cards are treated as Notes and, therefore, encrypted.

Lastpass DB parsed but still encrypted

The rest of the fields are not encrypted (including the URL and Type (item type, for instance, can be - bank account details): aid, URL, Favorite, sharedfromaid, Require Password Report, Generated Password, Secure Notes, Last Used, AutoLogin, Disable AutoFill, realm_data, fiid, custom_js, submit_id, captcha_id, urid, basic_auth, method, action, groupid deleted attachkey, attachpresent, individualshare, Note Type, noalert Last Modified, Shared with Others, Last Password Changed, Created vulnerable, Auto Change Password supported, breached, Custom Template, Form Fields

Lastpass DB parsed and decrypted

Expect such phishing emails soon Link to heading

So, while these vaults held protected (or encrypted) secrets, they also had additional data that LastPass decided not to encrypt. That additional information includes, among other things, the website URL of the service the password belongs to.

This isn’t very good in a couple of different ways:

  • This lets an attacker know what services you use, which is a privacy violation (GDPR?)
  • The URLs might include reset tokens or access tokens, which are not encrypted
  • Phishing emails can be made very relevant to the specific users

Crack the Master Password Link to heading

Wrong assumptions Link to heading

In the LastPass announcement, they claimed that it would take millions of years to crack the master passwords, which sounds reassuring. However, there are a couple of issues with that claim. First, this vast number of years is based on users picking a random password of sufficient length. However, the reality is often different, and attackers are not that stupid.

When asked to pick a strong password, most people would pick some phrases or words and add some letter substitution. For example, replace i' with 1` (which is sometimes called leet-speak).

Considering a truly random 12-character password will give us a space of about 2^72 different passwords. But as people are not computers, they tend to pick weak passwords:

  • they use only a subset of the available options - which are keyboard-accessible (sometimes called printable characters)
  • they choose passwords based on phrases or words - these are already known to attackers and exist in password-cracking dictionaries (e.g., rockyou.txt)
  • they will make simple letter substitutions, which also already exist in these dictionaries


The above realistically reduce the space from 2^72 to 2^34, more or less.

So what does this mean? Cracking a 2^35 strength password costs about $100. if you have a shorter password or pick a simple one, it would cost less and take a shorter amount of time (this assumes 100,000 iterations for the PKDF).


Strong master password Link to heading

12 character minimum was introduced in 2018, which is excellent. However, users with accounts created before that date were not asked to upgrade their password and can still use a lower limit (e.g., eight characters) as their password.

LastPass omits a pepper in their PDKF scheme. Pepper is a secret known only to the backend, used to augment the strength of the user-supplied password. The assumption is that users might have weak passwords, and including this “pepper” will allow them to strengthen their password security at a low cost.

So, What went wrong? Link to heading

LastPass made some product decisions along the (we assume), which led them to the current situation. As they did not want to migrate users to a more robust scheme (and thus make their security stronger), they decided to keep their settings as they were, even though they were aware of their weaknesses.

Some of the information they stored in the vault needed to be encrypted, probably to assist the product’s usability, for example when loading web pages and checking if the lastpass browser adds-on needs to kick in. Of course, they could have gone a different, more secure route, but we are guessing the product decision was made to keep things more straightforward and, thus, less secure.

Finally, it needs to be clarified how attackers could access and exfiltrate the user’s vaults - and why this was not detected for so long.

What can you do? Link to heading

Using a password manager is still a better alternative than not using one. Of course, there are many tradeoffs about usability and accessibility for your password manager, but it would still make you more secure to have unique passwords per service.

You should make use of MFA whenever any service offers it. This will allow you to protect your accounts even if the service passwords are exposed. Use MFA on a separate device (such as a mobile phone or YubiKey) for your critical accounts.

And finally, you really must choose a strong master password.

Choosing a strong master password Link to heading

The best thing you can do is use a randomly generated password of sufficient length. They are very strong but harder to remember. cat /dev/urandom | head -c 16 | base64

Another alternative is to take the XKCD approach, use 5-7 randomly selected words, and remember them. This is easier and still provides a secure option.

Finally, if you have a bi-lingual keyboard, you can cheat. Choose some phrase in your language, but type it using the English keyboard. This will create a seemingly random string of characters with sufficient length to be secure.