How did LastPass master passwords get compromised?

It's easy for me to imagine how you get here.

- Eng are still writing the postmortem

- Marketing want to put out a statement

- Eng know or suspect a bug exists that can trigger spurious notifications, but don't have sufficient logs to be able to reconstruct if that bug was in fact in play in production

- Legal advises not to say anything definitive that they can't stand behind later

I don't see any of that as particularly damning or malicious. "We aren't yet sure, but have a suspicion and are still investigating" can come out like the LastPass blog post when run through the PR filter.

That is the wording they have to use, right? They can't be certain that ALL the people who have seen these emails are caused by the buggy email notification code... I am sure some legitimate notifications were also sent out during the time, so how would they know if any of those were caused by something else?

I think they are sure they triggered some of the errors. However they may not be able to identify which ones were caused by their bug and which ones were legitimate attacks, which probably happen at some rate each day.

If you are a customer, and you received this message, you should definitely change your master password and probably rotate your stored passwords. You don't know if your email was real or not.

However, it explains why so many users were getting this message recently in a plausible way, that is not too hand-wavy except for their dodgy track record. Its not the level of transparency I would expect from Mozilla or even Reddit, but its par for the course.

You should probably migrate to another password store. I moved away a while ago for other trust reasons, but this particular incident on its own is not that concerning to me.

I've definitely used that exact wording when ALL of the problems were DEFINITELY triggered by something but I still didn't fully understand how.

One advantage of telling the truth is that you don't go to prison for fraud.

When evaluating this kind of conspiracy theory, it's important to consider the number of people who would have to remain silent for the conspiracy to survive, and to consider how much it would cost to keep that many people silent. In this case, it's at least a few dozen so I think it's fair to assume that such a lie would not survive very long.

The consequences of “Mea Culpa, please reset your master password” seem much less existential than denying and eventually being revealed as untrustworthy.

Except earning trust with the customer, in a line of business that is built entirely on the customer trusting you to manage things properly.

What's the difference between "triggered in error" and "sent out by mistake" then? In this context they seem like the same..

Some of the emails were probably real, and they just happened to have been when there was supposedly a issue. That can't part be definitive.

The lack of that specific information doesn't make it vague in my view.

If I tell to that the world appears to be shaped as a globe then that statement isn't vague just because I don't explain _why_ it appears shaped as a globe.

Several people have reported that if you tried to log on from a new IP with incorrect master password, then you got an email saying that someone tried to log on using your master password even though that was not the case.

There's little security advantage to doing this other than some obscurity, because a well informed attacker can still implement all the same attacks:

* An attacker with access to the database will know they can reduce the "hashing algorithm" to two sequential hashing algorithms and still bruteforce a series of plaintext passwords to check to see if the hash matches what is in the database.

* An attacker with access to the plaintext network communications or app server can just store and replay the second hash to login

* An attacker with access to the client machine can grab the plaintext password still

Lastpass does this is for end-to-end encryption reasons, where it is useful, but for standard apps I don't think it would be.

Everything you explain points at no need to do client side hashing: what exact attack vector would be stopped by having it? (The only thing you bring up is reuse of passwords, but then you explain how that would be easily exploited if server was compromised, and it's even easier if client is)

I would imagine most developers unfamiliar with encryption would assume that client hashing is sufficient and not bother with server side hashing which is the only one that ensures privacy in case of compromise on the server side (nothing really stops client side compromise).

WASM will do what you want.

You can certainly have client side JS produce a hash using some other credential as the salt and then encrypt the information server side. What you really lose is the ability to do low cost comparison, because most password hashing is done deterministically. Instead you would need to retrieve the record, decrypt with the server side key, and finally compare.

Use client TLS certificates and let the browser handle credential management, including at-rest encryption. Or use FIDO2 hardware. There are many options available but for probably familiarity reasons the vast majority of users and browsers didn't go down that path, and neither did website owners.

But then malware on the user’s machine could catch that password.

There is no 100% solution to this.

This sort of scheme is common so that you do not have to share the encryption key with the provider. You derive two keys from your plaintext password: one used for authentication and one used for encrypting / decrypting the blob. This way, Lastpass can authenticate you without having to see the key to decrypt your data.

Not sure the specifics of how lastpass implements this but this is a really common approach for end-to-end encrypted apps.

The client-side hashing is actually the part that keeps your master password a secret, from everyone including LastPass yourself. This makes sure that LastPass cannot decrypt your passwords despite them being stored there. The server-side part on the other hand is severely misimplemented and not much good to anyone. This is one of the issues I’ve written about here: https://palant.info/2018/07/09/is-your-lastpass-data-really-...

From what I understand: you still need the master password locally to decrypt the individual passwords. A hash won't provide that. All you're doing here is logging into LastPass.

Hashing client side has a non-cryptographic benefit of making all passwords a fixed length. This, in turn, helps avoid accidents with bcrypt misuse.

Consider if you have key logger logs you’d like to profit from. What do you look for? Login credentials is a good idea… which login credentials should you target? Password manager credentials seem like a good idea, since that gives you full login details for anything else else you might want.

If it is a group accumulating passwords via extensions it would make a lot of sense to me if they planned to sell them like credit card data on bulletin boards.

I don't think individual financial accounts would sell that well without really knowing if you have the necessary associated email accounts, etc to delay detection of a fraud.

I also don't think such groups are necessarily sophisticated enough not to have someone slip up at stage 2 of their plan, give away a few accounts to boast, etc, etc.

The formulation is vague enough that it could mean anything. Maybe the alerts were sent out by mistake which would be good news. But they don’t quite say that. Their statement might also mean that they rather disabled legitimate alerts so that people don’t get concerned. So they might have “cured” the symptoms without addressing the actual issue.

It certainly isn’t reassuring that they keep talking about credential stuffing, even though it’s quite unlikely to be the culprit here.

>Our investigation has since found that some of these security alerts, which were sent to a limited subset of LastPass users, were likely triggered in error. As a result, we have adjusted our security alert systems and this issue has since been resolved.

This added bit hints that these emails were erroneously sent in response to the wrong password being attempted against the master account (which normally doesn't rate an email). It isn't fully spelled out tho.

LP spends most of the blogpost going on about bad user practices - which feels a lot like gaslighting in this context.

edit: I'm leaning toward accepting LP's incomplete, forced explanation and that hackery isn't in play here.

It’s vacation time, they simply don’t have the people on site to investigate the issue quickly. So far not surprising, and certainly intended by the timing of this attack.

That their first reaction is to downplay rather than to admit that they don’t know much yet – that’s rather typical of LastPass unfortunately. Sadly, with this approach they aren’t exactly an outlier in the industry.

Yes, the sample is rather small to draw conclusions from. The biggest concern however are the people who got the notification again after changing their master password. It just doesn’t make sense if credential stuffing is what we are talking about.

First of all: I don’t think that all accounts are affected. For example, my own account didn’t receive this message. Assuming that indeed a logging server was compromised, we don’t know under which conditions the password hash is logged. Maybe it’s only people who used the web interface to log in, or only people who changed their master password, or people who hit a particular error condition.

Second: People only notice the failed login attempts. I don’t know what exactly this attack looks like, but I doubt that the point is triggering these alerts for as many people as possible. They rather want to log in successfully, meaning without any alerts being produced. Who knows how often this happened without anybody noticing?

Finally: We only know about people who were concerned enough about these alerts to write about it on Hacker News (or in some cases Twitter). That’s a tiny fraction of all LastPass users.

There are ways this scenario could manifest. The person submitting the passwords could have purchased them on the darkweb and may be figuring out how to use them. We'd be seeing the trial+error part of their learning curve.

Whoever first gets a hold of the password hashes would need to bruteforce individual entries or cross-check them against known leaks for reuse, which takes time. It's natural that they would only go after high value targets like famous people, cryptocurrency users, etc, then resell the database after they got as much value out of it as possible.

No, there is nothing. The complication with challenge/response schemes is that the server doesn’t know the master password – it only has that one hash, so it’s always comparing against it. There are PAKE protocols which work around this issue, but LastPass didn’t implement any of them (probably for historical reasons already, I think LastPass is older than most of these approaches).

Normally, it isn’t such a huge vulnerability. TLS encryption is there, so nobody should be able to catch that hash in transition. And even if they did, the most sensitive data is encrypted so that you still need the master password. Still, this is rather suboptimal.

I’ve given this some thought, but I think that this scenario still requires someone to attempt a login with correct credentials. It cannot be the legitimate owner however if the account hasn’t been touched for a year.

Even then there are locally hosted solutions like VaultWarden.

PassBolt comes to mind.

> There exists no computer system than can crack an AES256 encrypted document. The weaknesses are in the protocol.

Well, or in the human-chosen passphrase. There are plenty of systems that can brute force an 8-character alphanumeric password run through PBKDF2 for 100,000 rounds.

Per https://support.1password.com/pbkdf2/, that costs...about $60k.

So keeping the ciphertext safe is in fact a very reasonable precaution, especially if you have a fairly short input passphrase or are not using a ton of rounds of key stretching.

> Storing the encrypted database in the cloud and downloading it is the same as storing it locally if the decryption protocol is performed locally.

The problem is that, with web-based password managers, you are not only downloading the database, but also the code to decrypt it. A locally installed Keypass requires your PC to be compromised, whereas for LastPass it is sufficient for their servers to be compromised (while not avoiding the problem if you are compromised, either).

What about an offline password manager? Like pass[1] or one that supports the KeePass format. Then you could use your regular file synchronization tool to synchronize the database files. You could also use a P2P sync tool like Syncthing. (Of course this makes more sense if you already have some kind of file sync setup.)

[1] https://www.passwordstore.org/

The use of obscure and unintuitive terms would seem to hurt the objectives of security proponents to explain how systems have been compromised. If you tell me my credentials were "stuffed", I'm going to assume it was some technically sophisticated attack using some exploit or system vulnerability. If you tell me my password was simply stolen and posted on a website, and they're just brute force trying the password on all the systems, I'm going to know that my password has been compromised and some cybercriminals are out there using bots to try them everywhere.

In the first, case, I'd feel less empowered to do something about it. In the second case I'd be more aware of all the databases with old passwords in it and never reuse a password twice. (if that's what's happening).

Just curious if you had any information on the security concerns of 1Password from that researcher?

Been using Bitwarden and it works great, at least for personal use. And Authy for 2-factor

LastPass wrote that there was a bug causing these emails to be sent.

That may be correct, because several persons have reported reproducing that issue before the LastPass fix - they have written that they logged on with incorrect password while using an IP from another country and still got the email that their master password was used.