LastPass Breach (2H22) – FAQ

Background & Summary

LastPass released information on 22 December 2022 confirming that a threat actor had accessed backups of LastPass user vaults along with associated metadata likely connecting those vaults with customer identities.  Technically this was a further update on previous partial disclosures, indicating that a breach in August 2022 was worse than they had initially thought (or let on).

This is a bad headline for LastPass and its users, but the potential for an encrypted password vault to fall into the wrong hands is something that modern password managers are designed to be robust to.

Information is still scant, which also reflects badly on LastPass as an organisation, but here we summarise and offer our observations based on the information that has so far become available.

Any LastPass vaults managed by phew enforce strong minimum password policy and the costs associated with cracking your LastPass master password make this highly unlikely to be successful or worthwhile. But this is only true if your master password is unique and not discoverable or guessable from other sources (such as previous password breaches or public information about you).

This is a good chance to be reminded that no matter what password management solution you use if there is a master password that master password ABSOLUTELY MUST:

• Be as long and ideally as complex as possible (whilst allowing you to remember it without writing it down)
• Not be discoverable or guessable (and hence must also only be used for this one single purpose ever)

In terms of potential impact, if your master password and vault were cracked, the attacker would gain access to your LastPass master password as it was at the time that the vault backup was taken, as well as all passwords and other secrets contained in your vault at that time. Depending on your own assessment of your or your organisation’s risk, you might choose to change LastPass master passwords, along with certain other passwords, and you might take other steps with private information that is/was in your vault(s), so that an attacker who gained those secrets would no longer be able to use them.

You (or your users) are in the best position to know whether current, or any of your previous, LastPass master passwords didn’t meet these important requirements, and in this article we help clarify the considerations and actions you might take with the awareness of this breach, LastPass’s response to it, and the other information that has surfaced to this point.

FAQs

What happened?

LastPass confirmed on 22 December 2022 that a breach notified earlier in August 2022 did involve the threat actor accessing backups of user password vaults.

• So far the information is scant, which in itself reflects badly on LastPass. Since LastPass hasn’t said otherwise (and would have if they could have), we have to assume:
  • All user vaults were accessible to the threat actor (ie yours was probably affected)
  • The vault backups were not encrypted, or the threat actor had the decryption key for the backups
• The backups were of recent versions of the vaults (assume the latest date before the first announcement <– technically earlier can be worse, but that’s a separate point that isn’t directly relevant to this FAQ)
• That’s all we know. We so far haven’t heard any further information on vaults successfully being cracked, but we wouldn’t expect to hear of that in the short term either.

Without full information, what else should we assume is true?

• In assessing the potential impact, we should assume the worst unless there is clear and verified evidence to the contrary.
• So we have to assume:
  • This breach will result in multiple other parties gaining access to vaults (“vault crackers”)
  • This provides the opportunity for offline brute-force attacking of vaults by potentially multiple parties
  • LastPass hasn’t said who was impacted, so you have to assume everyone was
  • Although also not clear, we have to assume there is a way for the attacker to associate a vault with a username (email address), hence knowing whose vault they are attacking
  • We also know that the URL associated with vault “password” items isn’t encrypted, so the vault cracker knows which target (eg web site/app – “web service”) they are attacking the username and password for.
  • Assume the password is the important bit, because the username is probably the user’s vault email address in many cases
• In summary, therefore, we should assume an unlimited number of potential vault crackers attacking your vault as it has appeared at any time in the past, where the attacker knows your LastPass username as well as the URL of the web service.
  • If any such attacker cracks any one of those, then they have your master password
  • If they have your master password they have access to all secrets in your vault

Isn’t this really bad?

• It certainly isn’t good.
• It is, however, a scenario that modern password managers are intended to be resistant against.
• The bad scenario is that a password manager’s online copy of your vault leaks and becomes accessible to a threat actor.
• Why this is bad is described in “What’s so bad about this?“.

What’s so bad about this?

• The badness with this type of attack scenario is that the threat actor (and whomever they share it with) can launch offline brute-force attacks against your vault to obtain your master password (and hence everything in your vault).
• Although you need multi-factor authentication (“MFA”) to authenticate to the password manager’s services, and perhaps to any offline copy of your vault located on your PC, the threat actor doesn’t need your MFA when they already have a copy of your (encrypted) vault.
• The “offline” in an “offline attack” refers to the fact that a threat actor with a copy of your encrypted vault can attempt to brute-force your vault locally, eg on a PC or server, without going across a network. This allows the brute forcing to be done at a very high speed compared to say logging into your vault across the internet (which is very low-speed and can have lots of hurdles placed in front of it).
• These types of offline brute-force attacks are only limited by computer processing speeds (hence by time and money). However, even with current technologies, the time and costs associated with statistically likely, successful brute-force attacks against the types of encryption used by modern password managers, are very high. But this does assume that all best practices have been met, in terms of password length and complexity (these are things that can be enforced by technical policy within the password manager) and not re-using the master password in any other location (something that can not be seen or enforced by technical policy, and is exclusively within your knowledge and control).
• Whilst this scenario is indeed bad, it is also a very predictable scenario, and hence one of the main scenarios that modern password managers are designed to be resistant against. This is one of the main considerations in the convenience vs security trade-off of using a password manager that stores your encrypted vault in the cloud so you can easily access your vault from multiple devices and locations.
• The fact that LastPass vault backups have been subject to this scenario is also bad (for LastPass and its customers and users). It ultimately reflects negatively on their operational security practices. We’re not going to go too far down this path. Any exploit of this type reinforces the ongoing risk of exploits of users and the networked devices they are operating. Certainly, LastPass will be amply motivated (for as long as they survive) to improve their security policies, practices and technical enforcement capabilities, and there is clearly room for improvement. However, it is fair to predict that other password managers will fall victim to this scenario in the future also. As penetration testers, we know that there are holes everywhere, and the fact that LastPass was exploited isn’t the most pertinent fact here, as far as we are concerned. Sure, it affects which password manager you might choose to use in the future, and we comment more on that elsewhere, but there are more pertinent things to consider given that this scenario is a predictable one.

How hard is it to “crack” my master password?

• Taking the facts as described in other FAQs in this article, the key question is how “hard” it is for an attacker to crack the encryption in the backup copy of your vault that they may have obtained.
• “Cracking the encryption” essentially means successfully turning encrypted information in your vault back into something recognisably unencrypted (for example into a recognisable email address). If they are able to achieve that, they know they have the right master password, and they are then able to use that same master password to decrypt everything else in your vault. Notably, they don’t need to crack each item in your vault separately – cracking any one of them is sufficient. Also, the fact that your secrets themselves might look random and hard to recognise as the original “plaintext” when decrypted isn’t a problem either, since there are other more recognisable things in your vault that are encrypted with the same key (essentially master password), so once you have decrypted any of those other things you have the master password and can use that to decrypt everything else in the vault.
• That sounds bad, but how hard is it to crack any one thing in the vault?
• It is important to caveat, in answering this, that the answer depends very much on whether your master password is discoverable or guessable. See “What should your master password be like?” for more on this. When performing offline cracking, an attacker will always start with massive lists of common passwords and passwords obtained from other breaches (there are many publicly accessible such lists). It is only after they have exhausted those lists against however many target vaults they are attacking that they will bother moving on to either targeted attacks involving information that might be specific to you (and hence help reduce the search space for your master password), and only then would they bother moving onto brute-forcing with completely random combinations of characters. So if your master password might be guessable, or discoverable from some previous password breach, or from information about yourself that a targeted attacker might have, the following estimate does NOT apply to you, and the chances of your vault encryption being cracked are much higher (but we can’t tell you exactly how much higher).
• With that caveat, focusing on brute-force cracking of a password that is not otherwise discoverable, guessable or substantially weakened by other information the attacker has about you, we note the following:
  • Any LastPass master password in an account managed by phew has, at minimum, 59 bits of “entropy” (randomness).
  • To reach at least a 50% chance of a correct guess, you need to cover 50% of that search space.
  • That’s the same as assuming 58 bits of entropy, which is 2^58 guesses.
  • The algorithm used by LastPass, for all accounts managed by phew, performs 100,100 iterations of the relevant hashing algorithm (PBKDF2), which literally increases the cracking effort by a factor of 100,100.
  • So that’s 2^58 * 100100 guesses required to half-cover the search space of a minimum strength master password.
  • Recent reliable estimates suggest that it costs US$6 to perform 2^32 guesses. Cost is the most relevant consideration since that is the most limiting factor that can’t currently be compressed or parallelised away.
  • So, to have a 50% chance of cracking the password, you would have to spend US$587m on computer resources at current costs per maximum publicly available computational processing capacities.
  • That’s quite a determined attacker, and that’s for a master password that meets the absolute lowest of the minimum requirements (subject to the caveat as above).
• For completeness, and by contrast, it should be noted that:
  • If your LastPass master password is on some list of previously breached passwords, it is essentially cost-free for any attacker to get that password and gain access to the secrets that were in your vault backup.
  • If your LastPass master password is some smallish variation of such a password or is otherwise guessable based on public information about you, the cost to the attacker to try those variations is tiny. The cost is essentially US$6 for 4,294,967,296 (2^32) such guesses. Each guess requires 100,100 iterations, so let’s call it US$6 for 43,000 variations based on your other breached passwords and public information about you. An attacker might be willing to spend at least a few units of US$6 on you if they know you are someone whose secrets might give access to much more value than that.
• This hopefully demonstrates how critical it is that any password manager’s master password is BOTH:
  • Long and complex; AND
  • Not discoverable or guessable

What should I do?

• That depends on your assessment of the risk that your vault could be cracked as a result of this breach. We provide all the information required to make this assessment elsewhere in this article.
• The possible actions include:
  • Checking for evidence of master password re-use in your LastPass vault
    • See: “How do I know if my LastPass master password is reused elsewhere?“
  • Changing the master password for your current LastPass vault
    • See: “Should I change my master password?” and “What should my master password be like?“
  • Changing other secrets within your current LastPass vault
    • See: “Should I change other passwords in my vault?“
  • Adding MFA to accounts whose password exists in your LastPass vault and which don’t yet have MFA enforced.
    • See: “Should I change other passwords in my vault?“
  • Changing to an alternative password management solution
    • See: “Should we change to another password manager?” and “Are password managers just a bad idea, and I should use some alternative approach?“

How do I know if my LastPass master password is reused elsewhere?

• If your master password is also being used for any other item in your LastPass vault, LastPass has reports to highlight this.
  • For your own LastPass account under Security Dashboard (only visible if it is found to be true)
  • For a LastPass business account, this can be seen by your LastPass administrator in the Admin Console > Dashboard
• However, LastPass has no opportunity to know whether you have reused your master password in some location that isn’t recorded in your vault.
• It is possible to search password breach databases to discover whether your master password appears in any of those.
  • The most respected and well-implemented public resource for this is “Have I Been Pwned” (HIBP).
  • HIBP verifies and aggregates information from most password breaches in history and provides a number of services, including:
    • Email/phone number checker
      • Checks whether your email address has been involved in any previous password breaches of any type whatsoever (most addresses have been so don’t be surprised if yours has)
      • This doesn’t tell you whether your LastPass master password has been involved in a breach, however.
    • Password checker
      • Checks whether your password appears to have been involved in a previous breach from which HIBP has data.
      • We do not want to be in the position of actively recommending that you enter your master password anywhere except into LastPass applications.
      • However, there is an article linked from the top of the relevant HIBP page that describes how they deal with the password you enter into their form.
    • We do not provide direct links to these services as we make no representation or assertion about the security or otherwise of using HIBP or any such service. Please contact us to discuss this further if required.

Should I change my master password?

• At all times your master password must meet the criteria described in “What should your master password be like?“.
• If your master password doesn’t currently meet these criteria, you should change it.
• If your master password does meet those criteria already, then there is no reason to change it other than “more is better”.
• Changing your master password as a result of this breach does not affect whether the threat actors can crack the master password that was associated with the backup of the vault they obtained through this breach.
• If you think there is an increased chance of some previous master password for your LastPass vault did not meet these criteria, and hence has an increased likelihood of being cracked through this breach, then changing your master password now is a good idea, but it will only reduce the chances of future breaches.
• Since we don’t know when the relevant vault backups were taken, we can’t tell you when in the past this concerning previous master password of yours had to have been used.
• See “I have a LastPass account managed by phew. Does that mean my master password CAN’T be a weak one?” regarding whether it is possible for you to have had a weak master password in a LastPass account managed by phew.

What should your master password be like?

• At all times your master password must meet the following criteria in order to do the job you want it to do in protecting your and your organisation’s secrets. It must:
  • Be as long and complex as possible, whilst still being reliably memorable to you.
    • Password length is the most important consideration in password construction.
    • Password complexity (multiple character types) is a close second.
    • Being memorable just means you can reliably commit it to memory, and don’t have to write it down in order to use it.
  • Not be discoverable or guessable.
    • It should never be re-used for any other purpose. Hence a breach or disclosure of this password from any other service or location should not disclose your master password, or otherwise make your master password more guessable.
    • It should not be possible to discover the password from any information about you, your family, or any other passwords you use.
    • You have to assume that attackers will always start with:
      • Any disclosed passwords associated with your email address (from previous breaches)
      • Massive lists of common passwords
      • Variations of any information they might have about you and your family (noting that there is a lot of publicly available information about all of us)
      • Combinations of such information, with common separator characters in between (spaces; dashes; dots; commas; etc)
      • Only once they have exhausted all of these types of approaches will they bother with completely random brute-forcing of your password.
    • In short, your master password should be as random as possible, whilst still meeting the requirements of being long and reliably memorable.

Should I change other passwords in my vault?

• You should change other passwords and secrets in your vault if you think there was any reasonable likelihood of your master password being obtained by an attacker as a result of this breach
  • See “How likely is it that my master password can be brute-forced from this breach?” to make your own estimation of that likelihood.
• It is a higher priority to change passwords/secrets that can be used successfully without any additional authentication.
  • For example, credit card details can be used across the internet, say in e-commerce sites, often without having to provide any additional authentication. If you have the CC details (and those are still valid details, since the card hasn’t expired or been cancelled), you can buy things.
  • There might be other secrets that can be used online or offline without any additional authentication (ie having the secret itself is enough to use/exploit that secret).
  • This includes passwords for websites and services where you do not have MFA enforced. These are a higher priority than services where MFA is enforced.
  • Consider in particular:
    • Your domain registrar(s) and DNS service provider(s)
    • Storage service providers (eg Dropbox; Box; etc)
    • Your personal email and related services (eg Microsoft 365; Google Gmail and Drive; etc)
  • You might also consider passwords to services that would have a high impact if an attacker got access to your password.
    • Good examples include:
      • Your banking and other financial services
      • Your main email, data storage and business application services (eg Microsoft 365; Google Workspaces; Dropbox; Box; etc)
      • Your IaaS services (eg Amazon AWS; MS Azure; Google Compute; etc)
      • Your Single Sign-on (SSO) service provider, if that is different from the above (eg Okta; Auth0; [give others])
      • Your domain registrar and DNS service providers
    • Even with MFA enabled on these accounts:
      • Backups of the information in these services could give rise to similar exposure if an attacker had your password from a successful confirmation of your master password as a result of this LastPass breach.
      • Most forms of MFA are susceptible to phishing and other techniques to bypass or otherwise circumvent the additional protection offered by MFA. An attacker with your password has many options, and perhaps unlimited time available, to see whether they can get past your MFA (perhaps with your help) for that service.
• There is no single answer that applies to all of the possible dozens, hundreds or perhaps thousands of items in your LastPass vault, so it is a question of risk (specifically probability and impact) assessment in relation to both your master password itself and all of the other secrets that your master password is trying to protect in your vault.

I have a LastPass account managed by phew. Does that mean my master password CAN’T be a weak one?

• phew enforces strong minimum standards for master password length and complexity in all LastPass accounts we manage.
• Therefore it isn’t possible for you to choose an objectively weak master password in any LastPass account we manage.
• However, neither phew, nor LastPass, nor anyone else (apart from a well-informed adversary) can know whether your LastPass master password breached one of the other best practices listed in “What should your master password be like?“.
• For example, you might have a long and complex password, but if you used that same password for some other service or purpose, and that password became known through a breach of other disclosure relating to that other purpose, then it doesn’t matter how long or complex that password is. An attacker will just try that password as one of the first in their brute-force attempts against your vault. As described in that same FAQ, a smart (and more likely to be successful) attacker would try all such discoverable and guessable passwords against your vault before they wasted time and money trying random passwords.
• So, there is only so much that LastPass master password enforcement policies can do to help you meet best practice. We make good use of all those enforcement policies, but some of it unavoidably remains up to the user’s own exact choice of master password.

Shouldn’t my MFA protect me against this breach?

• Your MFA is relevant for authenticating to the LastPass service, and downloading your vault (which is then decrypted using your master password). This is relevant because one of the main breach scenarios we care about is threat actors not being able to authenticate as you and access your vault from across the internet.
• However, if a threat actor gets access to a copy of your vault (eg a backup of your encrypted vault, as in this breach) then they don’t require your MFA in their attempts to brute-force the encrypted information in that vault copy.

Has LastPass been negligent?

• Again, starting from the perspective that essentially anyone can be breached, the main focus is on what can be learned from that breach (specifically, what we can learn from this breach).
• The key thing we have learned from this breach is that LastPass hasn’t kept customer and vault security at the fore, or at least they haven’t kept pace with best practice as it has evolved over time.
• It is arguable that LastPass has been negligent in not doing so. It is also arguable that they made various small choices slightly on the wrong side of the “line” – with the line being where user convenience and corporate interest end and best practice security and user disruption start.
• Certainly, the lack of detailed information and transparency in the disclosure of this breach is perhaps the most concerning and definitive fact. This has significantly hindered the industry’s ability to advise LastPass users around risks and actions they should take, and we think LastPass will suffer the most as a result of this silence and opaqueness.
• On balance, we have learned things from this breach that are concerning and confidence eroding, given the type of application and service LastPass customers are relying on LastPass to provide.

Should we change to another password management solution?

• The first point here is that changing to another password manager doesn’t affect the likelihood of the master password (and hence entire vault) associated with this breach being successfully cracked. That copy of your vault is out there, and changing to another password manager can’t change that fact.
• It is relevant, however, to consider what we have learned about LastPass as an organisation, and some of the choices they have made. These are the best indication we have of the sorts of choices or omissions they might make in future.
• It is also worth considering whether LastPass, an product and organisation that stakes its entire business on the security of their password vaults and their management of those, can survive.
• We note that there are multiple strong alternative providers for this service, and whilst you can’t prove a negative (ie you can’t prove that these alternative providers won’t get breached in the same or some novel way), you also can’t un-see what you have seen. There is enough evidence in this LastPass breach of making the easier choice rather than the more secure choice, and of LastPass not quite keeping up with the constantly evolving threat landscape and industry best practice. These things aren’t as culpable as many commentators would have you believe, but they are nonetheless there and they are relevant to consider. Combining that with the much more concerning slow and vague disclosure that LastPass has so far provided, it seems we have evidence of an organisation that has fallen behind alternative service providers in terms of its practices, choices and transparency, for a type of service that demands the highest standards.
• All password management solutions we are aware of have trade-offs, often in terms of their functionality and particularly around policy enforcement capabilities. Certainly, their transparency and security architecture and implementation are paramount considerations, and there is a large degree of common ground between the major password management solutions in this regard (ie it isn’t especially easy to choose between them, subject to the other comments made in this article).
• As such, it may indeed not significantly affect the security of your vault in future if you were to change service providers, or indeed to change where your vault is stored (if it still needs to be accessible from the public internet). But where there is a choice, you may choose not to reward a service provider that seems not to have put its users’ security at the very top of their priority list, and who has demonstrated less than ideal transparency when a significant breach has occurred.

Are password managers just a bad idea, and I should use some alternative approach?

• It is far better to be in the habit of using a modern password manager in preference to other, less secure approaches to managing passwords. If you are considering giving up on password managers, note that all good services, including LastPass, are much more secure than other alternatives involving passwords. You are much better staying with LastPass than giving up on password managers as a concept.
• You might consider that a major platform vendor’s in-built password manager feature is a better option than using a solution from a smaller password manager vendor. Vendors such as Apple (through iOS and macOS), Google (through Chrome and Android), and Microsoft (through Windows and Edge) offer in-built password managers, and it is reasonable to assert that these very large and well-resourced organisations have implemented a secure solution in their products. The downside of this approach is vendor/platform lock-in, such that your passwords are sometimes not easily available across all of your devices, and not easily or securely shareable with users who are not on the same platform. Similarly, these major vendor solutions are not well suited to organisational use, where policy needs to be enforced across all users in the organisation. Certainly, any of these options is better than not using a password manager (with a strong and unique master password where relevant).
• You might have heard recent talk of “passwordless authentication” of different types, and of “Passkeys” in particular. Apple and Google released notable headlines in the second half of 2022 in this area. These are promising areas, but we have a long way to go before passwords are no longer required anywhere, and in the meantime, strong password management solutions and practices will remain relevant.
• As noted under “Should we change to another password manager?“, you are much better to be using any modern password management solution than using some alternative approach to password management, whether you choose a solution from an independent cloud-based password management provider, or from a major platform vendor, and whether you choose LastPass or any other solution (assuming you always use a strong and unique master password, with MFA enforced for authenticating to the service).