Live data from Hacker News

The situation at LastPass may be worse than they are letting on

twitter.com

361–370 of 436 posts

Re: The situation at LastPass may be worse than they are letting on

#362

Earlier quoted context omitted.

Aren't we assuming at this point that the attackers have the complete customer list? I imagine that it would be way easier for them to have a script query that list directly and search for names and emails to find high value targets, rather than reading through HN hoping for a hit.

This is news to me. Was the customer list also stolen? Specifically, customer records linked to individual vaults? My concern with anyone identifying themselves as being affected by this breach is that a 3rd party would be able to collect a lot of information about the user for a very targeted social engineering attack. Conversations here often disclose personal information such as approximate age, location, past exp…

From https://blog.lastpass.com/2022/12/notice-of-recent-security-... :

> To date, we have determined that ... the threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service. The threat actor was also able to copy a backup of customer vault data ... both unencrypted data, such as website URLs ...

Given how incompetent they've been, it would be safe to assume that the vault data is linked to customer account information. And because website URLs are included in the package, there is already tons of information for spear phishing, and any LastPass user here is probably already doxxed to the bad actor.

In general, you're right, but I really think that in this case the ship has sailed. The attacker has more information than they could possibly sort through by hand, they're not going to resort to reading forum posts.

Re: The situation at LastPass may be worse than they are letting on

#363
post #359

Being completely ignorant about how this works, why would a LastPass compromise result in passwords being exposed? Surely they themselves don't store unencrypted passwords, but instead the passwords are encrypted by the user's key? Or is this a compromise of the locally installed software?

The passwords are encrypted by a per-user key. That per-user key is derived from a password through a password based key derivation function (PBKDF). In essence, an iterative hashing function.

Many users don't use "good" passwords, so you use a high number of iterations on the KDF, to make it harder to brute-force an account's password.

Lastpass initially used 5000 rounds of KDF for old accounts. That's not a lot, especially today. They increased it over time to 100,100 iterations (which is better).

The data stored in a password vault is encrypted by a per-entry key, derived from this user password. If a user's password is weak, predictable, re-used, etc, then attackers now have an opportunity to decrypt the contents of their vault. Up until now, attackers generally have been assumed to not have access to user vaults, as that requires authentication (maybe including MFA).

No local software has been compromised, but getting a hold of the server-side backups makes it possible to try to brute force user's passwords in a way that was prevented by server-side rate limiting and MFA.

There is also some side information leakage from the server-side copies of users' vaults, like the URLs of websites in a given vault not being encrypted, and vaults being tied to user identities and contact info.

This tweet thread suggests/implies that at least one user has had a password compromised from information held in an encrypted vault. There's no evidence yet of a compromise of the locally installed software, but it emphasises the importance of changing passwords, moving to new wallets if seeds were exposed to Lastpass etc.

Re: The situation at LastPass may be worse than they are letting on

#364

Earlier quoted context omitted.

In theory, the master password is never supposed to leave your device even with the cloud-based password managers. So, yes, you're trusting that their clients do what they say they do, and I suppose an attacker could hijack the client and offload your password. That said, the same risk applies to any client you use. Someone could have compromised the latest update of KeePassX as readily as they can compromise LastPas…

Having to compromise KeePassX rather than Dropbox, and specifically while you are updating, is not an insignificant difference.

Having to do it while updating narrows the window of opportunity for sure, but I don't think KeePassX is a more secure target than Dropbox or Bitwarden.

They don't have to get bad code into an MR (though that's one option), they could compromise the website and have it distribute a different binary. If you build it from source you're safe against that, but are you really building it from source?

Also, remember that the same logic applies to Bitwarden: they need the master password and therefore must compromise the client during the window where you update it.

Re: The situation at LastPass may be worse than they are letting on

#365

So is there any way to verify what this person is saying? I mean, from the way LastPass is evolving it doesn't seem unlikely to me -- but why is this tweet on HN? Is there any supporting evidence aside from an anecdote, does this Twitter account have a strong reputation of being credible, etc.? Without context, I just don't understand why this anecdotal thread should be considered credible. Disclaimer: I use FOSS pas…

It was useful for me to know that website URLs and other metadata are not encrypted.

Re: The situation at LastPass may be worse than they are letting on

#367

Earlier quoted context omitted.

But that is the same claim that Bitwarden and 1Password make. Both insist that they don't ever see your master password, which means that your vault security depends entirely on it being good enough. And both encrypt everything. Assuming that I trust Bitwarden not to lie about their security model, what do I gain by piecing together multiple tools to accomplish the same thing?

Their software does see your master password. It may process it locally, it may not. If it's run in web client inside browser, that may change at any second. This may happen due to attack, their mistake, their dependency vulnerability or plain lie on their part. Fundamentally you need to trust them. In case of keepass and independent sync(doesn't have to be Dropbox), software that sees master password doesn't need ac…

> Their software does see your master password. It may process it locally, it may not. If it's run in web client inside browser, that may change at any second. This may happen due to attack, their mistake, their dependency vulnerability or plain lie on their part. Fundamentally you need to trust them.

All of this applies to KeePass, minus the browser extension bit (which is trivial to avoid by not using the browser extension). The only difference is that you can theoretically firewall KeePass from the network, which I'll grant you would make a difference, but the fact that you reserve that for the extra paranoid suggests most don't do that.

> because there's no single party that is even able to screw up you to the point of leaking your passwords

Again, only true if you block network access. If not, you have as many points of failure as with Bitwarden, because only the client needs to be compromised to get both vault and password.

> Also - why pay recurring fee for yet another cloud storage, when I just need plain encryption software.

Bitwarden free is plenty for me right now, so this doesn't play into my calculus.

Personally, I'm not interested in making the switch if I'll have to fiddle with firewalls on all my devices in order for it to be more secure for my current solution. It's not that this conversation is made me think less of KeyPass, it's that I'm yet to see a convincing argument that Bitwarden is worse than what I would end up with in practice by switching.

Re: The situation at LastPass may be worse than they are letting on

#368
It is highly unlikely that the attacker was able to crack the encryption. It's also highly unlikely that Lastpass had an unencrypted copy of the vault. However we know that all URLs are not encrypted which allows to identify users who have accounts for particular services e. g. cryptocurrency websites. The attacker could mount targeted attacks only on these lastpass users to reduce the risk of raising red flags. For example the attacker can send very convincing phishing mails to target these individuals with 0-day exploits. But an alternative much more scarier scenario could happen if the attacker found a way to extract the lastpass master password by injecting malicious code into the lastpass extension of targeted users. The possibility of this scenario depends if there is a way for lastpass servers to inject code into the browser extension.

Re: The situation at LastPass may be worse than they are letting on

#369
I tend to stay away from centralized password managers like last pass too risky and too big a target. I use and recommend KeePassXC for local password management. This is a similar problem to keeping your crypto on a centralized exchange vs in a cold wallet. There are trade offs to doing it this way, but to me it is the best and most secure option. I rather control my passwords or keys than some company.

Re: The situation at LastPass may be worse than they are letting on

#370

This is ultimately a predictable outcome for any password manager that stores your credentials on someone else's server. Just like they say in crypto "not your keys, not your crypto" - it applies here too. Not your storage, not your passwords. KeePass on an airgapped box, or an encrypted hardware password manager with no network interfaces is best, though frankly, I'd even be more comfortable writing down passwords o…

> KeePass on an airgapped box

Sounds inconvenient for password retrieval when not home, how does this work in practice?

How about an airgapped phone with GrapheneOS and Keepass?

Post reply on HN