Late last month, LastPass disclosed that they had suffered a breach, exposing customer contact information and source code to the company’s applications. Today, they disclosed that the bad actor also obtained copies of customer’s encrypted password vaults. On the surface, one may consider this “bad”, but not “catastrophic” due to the presence of a master password that “nobody but the customer knows”. Unfortunately, it turns out that only portions of the vault are encrypted. Notably, URLs for which you have stored passwords are not encrypted. So, the bad actor knows the website for your bank, your email provider, your paycheck stub, your doctor/hospital, etc. All of this is extremely useful in phishing attempts.
At this point, LastPass customers need to think about the strength of their master password and consider changing passwords on their “important” (or all) web sites. And, like everyone, they need to remain vigilant in their phishing defenses.
If this inspires one to select a new password vault provider, I encourage selecting one that encrypts the entire vault and has an MFA option for protecting the vault contents.
@denbesten wrote:If this inspires one to select a new password vault provider, I encourage selecting one that encrypts the entire vault and has an MFA option for protecting the vault contents.
Wise advice. I just don't trust any online password manager. The fatal flaw of all password managers is that you're dealing with encryption (as opposed to hashing) meaning those passwords are recoverable./decryptable. Using a local (vs. online) manager seems to make the most sense. Your ciphered passwords and key will all be under your control. If you lose the device etc., you'll be facing trouble, but you will know it. If you forget your cellphone in cab, it stinks, but you know it and can start changing passwords before some thief even knows what they've got. You don't have to wait in the dark for a few months until someone has figured they've had a data breach.
@JoePete wrote:Using a local (vs. online) manager seems to make the most sense.
Fair point, but it is important to note that this is an individual risk-acceptance decision.
Neither concern is more correct. The trick is deciding which one best matches your individual needs and risk tolerance.
In any case, one must protect the master password at least as well as they protect the most sensitive password in the vault (e.g. length, complexity, MFA).
I do presume both Joe and I are referring to vaults that encrypt locally and store encrypted vaults the cloud. Pure-cloud vaults (i.e. no local app, no browser extension, accessed solely by web page) expose your unencrypted passwords to the cloud provider when you enter it and when you retrieve it. They have a whole different level of risk acceptance.
@denbesten wrote:I do presume both Joe and I are referring to vaults that encrypt locally and store encrypted vaults the cloud. Pure-cloud vaults (i.e. no local app, no browser extension, accessed solely by web page) expose your unencrypted passwords to the cloud provider when you enter it and when you retrieve it. They have a whole different level of risk acceptance.
A pure-cloud model certainly would be more worrisome. My focus was mostly on the notion of encryption vs. hashing. We have learned to trust that our password to access a service provider is hashed. The average user may make the assessment "if I trust them with one password, why not trust them with all of them?" Barring overt simplicity - a hashed password will be unrecoverable. An encrypted password vault will always be recoverable with the right key. It becomes a more involved assessment, especially if we are talking a vault synced across multiple devices. There are ways of doing such things really well. There are also ways of doing them very poorly. Distinguishing one from the other is very difficult since typically we can't see beyond the submit button.
Absolutely, it is a matter of distinguishing different types of risk and which suits an individual better than others. Maybe because I entered security through the development side, I don't trust developers 😉
@JoePete wrote:
Maybe because I entered security through the development side, I don't trust developers
Your Dec-2022 comment is pointedly on target, given an update that came out in Feb-2023:
... they specifically targeted one of these DevOps engineers and infected their home computer with a keylogger. Once this engineer used their home computer to log into the corporate LastPass vault, the attackers were able to access all the data.... the engineer was running an earlier, unpatched version of Plex Media Server on the engineer’s home computer.
Also interesting from the same article:
the breach affects LastPass users who had an active LastPass account between August 20 and September 16, 2022.
And, it appears that things continue to get worse.....
Experts Fear Crooks are Cracking Keys Stolen in LastPass Breach [Brian Krebs]
Seems that although Lastpass routinely adopted newer/better/stronger encryption mechanisms for new customers, existing customers were kept at their existing encryption level and not advised to update.
@denbesten wrote:
Seems that although Lastpass routinely adopted newer/better/stronger encryption mechanisms for new customers, existing customers were kept at their existing encryption level and not advised to update.
This circles to the discussion about NIST password recommendations and whether passwords should be changed. I suspect the only way to take advantage of the stronger encryption scheme would have been to reset the master password.
There are certain features that just "smell bad" from a security standpoint. Putting all your passwords in some Internet-accessible resource might facilitate the opportunity to create good passwords, but it puts you one data breach away from a compromise of your entire life.