> 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.
Source: https://blog.lastpass.com/2021/12/unusual-attempted-login-ac...
Source2: https://twitter.com/troyhunt/status/1476296988001849345?s=21
“SOME of these security alerts” “were LIKELY triggered” “HAS BEEN solved” (Emphasis mine)
How can the issue be definitely solved if you aren’t sure that they were actually triggered in error, if they were in error then it’s only some of them.
- 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.
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.
1. lie about it and the truth never comes to light
2. lie about it and get caught and the consequences are the same as if you came clean
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.
It certainly isn’t reassuring that they keep talking about credential stuffing, even though it’s quite unlikely to be the culprit here.
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.
> We then take that value, and use a salt (a random string per user) and do another 100,000 rounds of hashing, and compare that to what is in our database.
https://blog.lastpass.com/2015/06/lastpass-security-notice/
While it's true that the client-side hashing means that LastPass never sees your plaintext password, the first hash effectively becomes the password. Then it's on LastPass to treat it as such, which they claim to do by hashing it again.
Edit: another link describing the use of PBKDF2:
https://support.logmeininc.com/lastpass/help/about-password-...
[1]: https://github.com/cfrg/draft-irtf-cfrg-opaque
[2]: https://blog.cloudflare.com/opaque-oblivious-passwords/
Unfortunately the only way I know how to implement that is to have the server send JS down to the browser that instructs it to perform the hashing. For certain types of compromises server side, the attacker would just modify the JS to get the unhashed password. I'd also need to fall back to pure JS hashing for old browsers (5% users?), so there's a UX concern if I perform lots of rounds.
I kind of wish there was a different password HTML field that could run the client side hashing without JS, so the browser would manage that. Ideally using different UX so the user understands they are using a "safe" password field. The end result would be to deny access to the raw password, which is likely reused on multiple sites.
* 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.
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).
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.
There is no 100% solution to this.
Not sure the specifics of how lastpass implements this but this is a really common approach for end-to-end encrypted apps.
That logic doesn't really make sense. Malware might make hacking LastPass accounts unnecessary, but it would still be highly desirable (one target gives you everything else).
Frankly, it feels like OP decided on the conclusion before any analysis was done.
Malware doesn’t seem to fit to me.
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.
Recent and related:
LastPass Login Attempted Activity Blocked – More Information - https://news.ycombinator.com/item?id=29731317 - Dec 2021 (12 comments)
LastPass says no passwords were compromised following breach scare - https://news.ycombinator.com/item?id=29723319 - Dec 2021 (68 comments)
LastPass users warned their master passwords are compromised - https://news.ycombinator.com/item?id=29716715 - Dec 2021 (313 comments)
Ask HN: How did my LastPass master password get leaked? - https://news.ycombinator.com/item?id=29705957 - Dec 2021 (508 comments)
> Our initial findings led us to believe that these alerts were triggered in response to attempted “credential stuffing” activity [...] We quickly worked to investigate this activity and, at this time, have no indication that any LastPass accounts were compromised by an unauthorized third-party as a result of these credential stuffing attempts, nor have we found any indication that user’s LastPass credentials were harvested by malware, rogue browser extensions, or phishing campaigns.
> 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.
[0] https://blog.lastpass.com/2021/12/unusual-attempted-login-ac...
It certainly isn’t reassuring that they keep talking about credential stuffing, even though it’s quite unlikely to be the culprit here.
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.
I am unsure if this is too small of a compromise for them to be able to a) care or b) spend resources on investigating or that they just don't know what's happening.
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.
It's possible the old accounts could be some old stock sold on a darknet forum and are being bundled in with the newer hashes/pwds. It's also possible that the entity harvesting the newer hashes/pwds isn't the same one who is amateurishly attempting to access the accounts.
Note: Lastpass's geolocation may be off (even more than usual for geolocation) as some of the IPs are in ownership dispute and all of them may be for VPNs.
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.
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.
Thoughts on this as a possible root cause?
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.
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).
This seems par for the course, I can’t imagine any credible company or keen user actually using lastpass at this point.
*Not secure: It will always catch you off guard, and will require a lot of work, so you will postpone it which is, not secure.
Were those requests the ones that triggered the emails that many of us received, and were those requests made with the correct or incorrect passwords?
Do you have an explanation why some people changed their LP passwords, and then received another login attempt alert email after that? Is that a coincidence (i.e. it was just more incorrect credentials still being tried on the same accounts) or was the attacker aware of the password change? Did the attacker have access to the new password or not?
Many of us received the alert email that our passwords had been used (i.e. an attempted login with the correct password from a new IP), but swear that those were unique passwords (in my case, it was computer generated, locally stored in KeePass and never re-used -- many other cases like that). Did the attackers have our passwords in their possession, or no?
To be fair to them, I don’t think we’ve seen any reports of folks password DBs actually being compromised. Just a lot of presumed failed attempts.
If the e-mails were sent in error, then it’s all much to do about nothing. If the master passwords were actually compromised, then the system still successfully protected the clients password assets.
Could be some crazy coincidence but what Lastpass is saying isn't adding up.
https://www.securityweek.com/credential-stuffing-successful-...
The term "credential stuffing" is a bit counterintuitive for me as well, but I guess it fits the pattern of credential attacks. "Password reuse" has other meanings, so would be less precise as a technical term.
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).
Note that 2FA with SMS is much less safe than a code generator app, since it is much easier for someone to get access to your phone number than to get access to the code generator.
The trouble is that the majority of their competitors isn’t great either. I used to recommend 1Password, but another knowledgeable security researcher isn’t really fond of them.
It's like data management in general: If you don't uniquely, personally control it, you don't really control it.
It is hackers using existing compromised email/password combinations on brute force attempts at Lastpass.
That is why your Lastpass password should be a password that you have not nor will ever use on any other site.
However, at the moment I'm not satisfied that a compromise has been demonstrated, either. As near as I can tell, nobody has reported a compromise, just suspicious emails. That's not enough evidence to prove a compromise.
LastPass' response, so far, adequately covers what we've actually seen.
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.