palant

Disclaimer: I’m the author of this article.

I’m not missing anything. It’s LastPass who finally need to retract this article. I proved back in 2018 that server-side iterations are misimplemented and have no security effect. That’s why they increased the client-side value in the first place. See https://palant.info/2018/07/09/is-your-lastpass-data-really-...

Disclaimer: I’m the author of this article.

I don’t think so. 346,000 guesses four years ago was for the old default: 5,000 iterations. 88,000 guesses is on more powerful hardware but with the new default: 100,100 iterations.

Disclaimer: I’m the author of this article.

No, the iteration count is no secret. It’s even exposed via a public API, anyone can query it if they know the email address.

Thank you for this confirmation. I already suspected that LastPass failed upgrading people’s security settings for each change of defaults they made. But so far I’ve only seen one person who found an account with one iteration (that was their very first default). Now you gave me two more.

It isn’t. You certainly used MD5, SHA1, SHA256 or SHA512 as hash, with SHA256 being the most likely one. All of these are very easy to bruteforce – if someone has one of your passwords, bruteforcing your master password won’t take all too long.

You just exposed all your passwords to bruteforcing attacks. Unless “hash” in this case is something like scrypt with sane parameters.

Originally (before I started writing my own password manager) I also thought that this is a safe method of password generation. And then I realized that it isn’t. Wrote about it here: https://palant.info/2016/04/20/security-considerations-for-p...

Thing is: this is the third article on the topic I wrote in the past few days. Covering your options wasn’t the goal here, it’s in the first article: https://palant.info/2022/12/23/lastpass-has-been-breached-wh.... Particularly the “executive summary” at the start.

As to the “speculations”: I have sufficient experience with LastPass press releases to assume the worst whenever they omit details that they should definitely know. On a number of occasions they covered security vulnerabilities that I found, and I know how they operate.

Mind you, I would be more than happy to learn that I’m wrong. But this isn’t a situation where “hope for the best” is a viable approach.

Note: I did not claim that LastPass is storing master passwords. They claim that they built their system in a way that they cannot. And I merely point out that this isn’t true: they could have built their system in such a way, but they chose not to, despite being warned about it repeatedly.

Browsers’ built-in password managers certainly have above average quality, at least when used as a purely local solution. A while ago I listed typical issues of the browser integration in password managers, browser vendors have it all covered. Except for #5 where they opted for convenience: https://palant.info/2018/08/29/password-managers-please-make...

This doesn’t mean that they are perfect. While Firefox allows you to choose a master password for your local password storage, even after improvements this is a very weak protection: https://palant.info/2018/03/10/master-password-in-firefox-or.... From what I remember, Chrome doesn’t offer any local protection whatsoever – if somebody manages to copy this data off your computer it’s gone.

More critical aspect is the sync functionality: https://palant.info/2018/03/13/can-chrome-sync-or-firefox-sy.... Following my report, Chrome Sync has been improved and now offers reasonable protection at least for passwords – assuming that you set a passphrase which isn’t the default. In principle, Firefox Sync is better because it always encrypts all data, not merely passwords. But its bruteforce protection is very weak, the bug report I link to is still unresolved. So you would need a really strong password to protect the data (ideally randomly generated).

Disclaimer: I am the author of this article.

What kind of pragmatism would you prefer? LastPass messed up way more than they are willing to admit. And it’s not like nobody warned them before, quite a few of the issues which turn out to be very problematic now aren’t news – I brought them up years ago as did others. LastPass should be warning users now and suggesting mitigation steps, instead they claim that nobody has a reason to worry.

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-...

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.

It’s rarely actual security concerns, mostly how they deal with security issues when they are reported to them. I’ve never had to deal with 1Password in this way, the code I’ve seen was pretty solid. This researcher made some rather bad experiences however.

No, modern PAKE protocols work without the server actually knowing the password. The server has a “verifier” that lets them tell whether the client’s response to a given challenge is correct. I’m no expert on this topic but https://blog.cryptographyengineering.com/2018/10/19/lets-tal... is a good start.

The difference is the word “likely” which means as much as “we have no idea.”

I haven’t seen it when I wrote the article. However, 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.

I’ve written about their security story a while ago here, not much has changed since AFAIK: https://security.stackexchange.com/questions/45170/how-safe-...

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.

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.

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.

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.

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.

I am the author of this article. I’ve kept it short, some points made there could have been expanded considerably. So if there are questions, feel free to ask here.

Yes, I’ve already seen this. I’ve written https://palant.info/2021/12/29/how-did-lastpass-master-passw... discussing the possibilities here. So far the most likely suspicion is that LastPass infrastructure is compromised and a pass-the-hash attack is going on.

It’s unlikely to be due to a browser extension. A browser extension that can steal your master password can steal all the other passwords as well, it doesn’t need LastPass for that. More importantly, an extension can only steal your master password when it is used – yet several people reported not having used LastPass for a year or more. It’s still not impossible that an extension has been stealing master passwords for years only for them to be used now, it’s merely unlikely.

Judging by the reports here, the source of the leak appears to be LastPass after all. Given that most people write about old accounts, my original suspicion was https://palant.info/2018/07/09/is-your-lastpass-data-really-... – from all I know, LastPass never investigated whether that websiteBackgroundScript.php issue was already being abused. It was obvious enough that someone might have discovered it independently of me.

If on the other hand you changed your master password recently (and someone had a login attempt on a brand new account) then this theory is moot. While I am aware of a number of LastPass design flaws (see https://security.stackexchange.com/questions/45170/how-safe-...), none of them could be the culprit here. It must be something new then. The weird thing: LastPass must have stored unencrypted passwords somewhere, because reversing 100,000 rounds of PBKDF2 wouldn’t have allowed such large-scale attacks.

It definitely is a hard problem. Clearly, if anybody at Avast bothered to look at the data they would have spotted the issues. But even with real effort, it’s hard to anonymize data reliably while keeping it useful.

I am the author of this (slightly older) article. If there are questions, feel free to ask here and I’ll do my best to answer.

“Data collection outlined here” refers to both mechanisms covered by the article. The first one collects information about the products you look at which clearly is personal information. The automated scraping in the background is less problematic from the privacy protection point of view, at least when it is used in the intended way.

Unfortunately, it isn’t that easy. You cannot use other extensions to block requests happening on the extension’s background page. Whatever tracking and scraping is going on, you can probably disable part of it via extension’s settings but otherwise there is nothing you can do.

Note: I am the author of this article.

I’m really unsure how you would come to this conclusion. Even if you only read the summary at the beginning or only the conclusions section at the end, you should notice that Keepa is doing both. It will extract data from your Amazon visits (personal information) and do its own scraping (merely wasting your bandwidth if implemented correctly which I am unconvinced of).

No, it isn’t PII in the legal sense, it doesn’t allow identifying you directly. Which doesn’t mean that it cannot be tied to your identity. Just one example: if you regularly post to social media what you bought online, this information could be correlated with the Keepa data to find out which profile is likely yours and what else you looked at.

But GDPR doesn’t merely require you to disclosure collection of PII, but rather all data collected. There is a good reason for that.