121–130 of 189 posts
I stopped using lastpass a couple years ago now due to ill-communicated master password leaks, ever-rising fees, and buggy UX. This seems par for the course, I can’t imagine any credible company or keen user actually using lastpass at this point.
Earlier quoted context omitted.
This is broken thinking built on faulty assumptions. There are countless examples of massive conspiracies and secrets never leaking.
Can you provide some? I have previously only heard "santa".
What are the chances these emails were actually sent out in error, like Lastpass claims? It’s not in-plausible, but I also take it with a grain of salt. 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 comprom…
Could be some crazy coincidence but what Lastpass is saying isn't adding up.
I'm suddenly very grateful for Lastpass wanting to charge me, and me leaving
Earlier quoted context omitted.
Which to me begs the question: then why hash client-side at all? What are the threats it protects against?
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 en…
As in, the idea is that it is used to save you from having two secrets which might be more or less easy/hard to remember.
It's a UX improvement (which might be a security imorovement on average too).
So this blog seems to completely ignores LastPass statement from 2021-12-28: > 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:…
That statement is too squirrelly for me to trust if my passwords were stored with them. “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.
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.
Earlier quoted context omitted.
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.
I was referring to the IP's being shown to users.[1] So then; Is the bug also responsible for pushing bad data to the users dashboards? If this is really a bug, it's a complicated one. I'd be curious if those IP's are still being shown on the users end. [1]: https://news.ycombinator.com/item?id=29705957
Why would it need to be a complicated bug? It could be as simple as:
If UnkownIP OR InvalidMasterPassword Then LogAndSendNotication
Instead of:
If UnkownIP AND InvalidMasterPassword Then LogAndSendNotication
Please tell me why it needs to be a complicated bug.
Earlier quoted context omitted.
"Credential theft occurs when attackers breach a system and steal users' access credentials -- usually ID and password. The ID is most commonly the user's email address. Credential spilling is when those credentials are made available to other criminals. Credential stuffing is the large scale use of automated means to test stolen passwords against other unrelated websites." https://www.securityweek.com/credential-stu…
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…
Researchers will sometimes modify services to log password attempts in plaintext in order to try to determine where stuffed credentials are coming from, but for obvious reasons it's not advisable to do this on a "real" service, so it's usually hard to know exactly what's going on---although the set of attempted usernames can sometimes give you a good hint, for example it's not at all unusual to see credential stuffing attacks where the attacker hasn't even enumerated users and is just trying common usernames. Some of these common username lists are kind of eccentric and you can recognize which one an attacker is using by some of the odder entries on it. I've had instances where googling a particularly weird username out of authentication logs just turned up exactly the perl script the attacker was using, uploaded to some compromised webserver where Google got wind of it somehow. I assume the username list it was using was originally from some real system but had been copypastad until it no longer had any relation to the original source. A lot of common password lists are like this as well.
The term "credential stuffing" should be viewed as a term of art and not used in communications to the public, but I do think it's useful because it describes a phenomenon which is different from, and may or may not involve, password reuse by users.
As a semi-related but amusing anecdote, there was for a time a fairly large-scale SSH credential stuffing effort by a botnet whose operator had made a mistake and mixed up the "username" and "password" fields in their credential list. Many SSH servers saw thousands of attempts with various usernames like "letmein123" and password "root" or "admin". I suspect the actual root of the problem was that they'd concatenated credential lists, not realizing they were in different formats. They may have even gotten the credential list that way, these things get passed around in really haphazard ways.
Earlier quoted context omitted.
No, they say "As a result, we have adjusted our security alert systems and this issue has since been resolved." They are claiming they know what the bug was.
They *need* to go into great detail if people are supposed to trust them with their digital life. That statement isn't nearly enough.