It's not the wording they could use if they were sure that at least one alert was sent in error; then they wouldn't say it was likely, they'd say they know there were erroneous alerts. As it is, they're just speculating the alerts were wrong, which bodes very poorly.

> eventually being revealed as untrustworthy

Replace "eventually" with "maybe".

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

I agree that the security industry has a problem with inventing new terms when they don't contribute to understanding. I do think there is some nuance here though to "credential stuffing" vs "password reuse" - credential stuffing is a description of the exploit while password reuse is the vulnerability. In other words, password reuse is a user behavior that doesn't directly cause unauthorized access. "Credential stuffing" is described from the perspective of the service provider, which sees an attacker "stuffing" many thousands (often hundreds of thousands over time) of credentials into their product to see if any of them work. Of course only a tiny fraction do, but that's enough to create a big problem. It's usually not clear where the stuffed credentials came from, it may be a check to see if compromised passwords from other websites were reused, but more often credential stuffers just try a "top 100" password list against every user they can enumerate---so password reuse per se or a compromised credential list may not even be involved, just use of common passwords.

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.

Very interesting and would set my mind a bit more at ease.

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.

I assumed the point would be to store all of the salt values ever used server side and never allow reuse of a salt. That way if the hash is captured but has already been used then it is useless.

Different problems need different solutions. I don't think I've ever seen a solution that solves 100% of all problems. This doesn't stop me from trying to improve security where I see opportunity.

Malware on the user's machine could catch the password in either case.

I simply use a 40ish character passphrase. My primary attack vectors are keyloggers/local malware and browser/extension vulnerabilities, which also apply to a local ciphertext.

You are correct: if the password used to create the key is trivial, then there definitely exists hardware that can guess AES256 passwords even if a KDF is used weakly.

I'm not sure how to read that table. Is that really the cost for a 100,000 iteration PBKDF2?!?

This isn't some abstract argument about your view of the world. This is a blogpost about a potentially very serious system fault. Customers want to know what the root cause of the fault was, so that they can evaluate whether to continue to do business with the company or not. It's very cut and dry.

It's vague because we don't know why you consider it to appear to be a globe. Did you fly in a rocket and saw it or do you just think that round is the perfect shape and God wouldn't create the world in any other way?

Can you explain how PAKE would help here? Going just off Wikipedia, it is a key-establishment protocol "based only on their knowledge of a shared password". So I would expect that the shared password is the master password or its hash and the parties are the user and the LP server. So wouldn't using PAKE require the server to know your master password or its hash? That sounds the same as before. Is the idea that they both know the hash only transiently (instead of the server knowing it persistently as it does today) and then establish some other key which they use after that?

I wouldn't say it's so you don't have to share the encryption key with your provider (you achieve that with a separate encryption key), but rather so you can use a single memorable secret for both login to the provider and local encryption.

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

Oh I see, so the master password is like a seed for multiple things: the password hash, but also e2e encrypting the passwords.

That makes complete sense, thank you for the answer.

> erroneously sent in response to the wrong password being attempted against the master account

This seems likely. After the original HN post, I went to delete my LastPass account as I've been using Bitwarden for several years. I initially used the wrong password, but then successfully logged in.

I got the alert email in question, so either it was sent in response to the wrong password (incorrectly) or it was sent in response to the full login, which of course wasn't blocked. The former seems more likely to me.

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

He spends most of the post dismissing user error. That looks very reasonable to me, as those are the most likely issues by a large margin.

I've only seen client certs used in contexts where an IT department assigns them to employees. Has anyone had success with these on public facing websites?

Extra hardware seem cool, but I've also rarely seen people using them. I'm guessing the added cost is a deterrent.

That would be roughly equivalent to lastpass then.

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

Your analysis seems to overlook an important detail in that first bullet point - dictionary attacks are only feasible when the KDF is fast. Authentication servers tend to require the KDF to be fast so they aren't constantly performing a denial of service attack on themselves. What people are looking for is a way to make the combined KDF slow by pushing most of the work to the client side. If this succeeds, you have made dictionary attacks very difficult without making your authentication process a denial of service vector.

The web browser ecosystem makes this a pretty hard task, unfortunately. You need fallbacks that weaken the process to the point where it is basically useless in a lot of cases. But the goal of a client/server split in the KDF is actually quite sensible. The client side does the large amount of work to protect users from dictionary attacks. The server side does a relatively much smaller amount of work to protect itself from being easily exploited if its hashes are exfiltrated when the hashes aren't themselves vulnerable to dictionary attacks.

It does prevent inadvertent logging of passwords, though: no piece of software on the server side will have the user's password in memory at any point. Which does mean the user's actual password (if they're reusing passwords) stays more secure (by "more secure" I mean "has a lower probability of leaking to a malicious actor", not necessarily "has some additional security properties").

If we add client side hashing, it does nothing to prevent hash replay attacks. Agreed.

However, it prevents the attacker from immediately trying the same raw password on other sites (i.e. credential stuffing). They would need to perform additional offline attack of the first hash. This adds cost to something that would have previously been trivial.

Given that about 65% of users reuse passwords and 76% don't even use a password manager [1], I think that slowing down credential stuffing attacks is important.

Protecting against some attacks is valuable even if you don't protect against all attacks. Layered security.

1. https://services.google.com/fh/files/blogs/google_security_i...

Okay, I don't wanna go into a fight over Lastpass because I don't know its tech deep enough to make a judgement (and HN reply limit would prevent it anyways). My point is, there are still some general differences between an online password manager and an offline password manager + file sync combination:

- There's no way a flaw in an authentication protocol could compromise a master password (because the file sync software is completely detached from the password manager).

- Someone who compromised your master password can't get your passwords without first obtaining your database files.

That being said, I don't think online password managers are inherently insecure or anything like that.

A few dozen, most of whom took a job at a security firm and one might imagine are the type reluctant to maintain a lie like this.

This is broken thinking built on faulty assumptions. There are countless examples of massive conspiracies and secrets never leaking.

you’d need a microscope to see the overlap in the vein diagram of people who lie at work and the people who go to prison for lying at work.

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

This is a very unlikely expectation. Employees are under NDA so nobody will talk publically about it unless one of them feel so strongly about it to sacrifice their career (they'd certainly get fired, and being sued for breaching the NDA isn't going to make finding a new job easier).

Employees at all companies keep quiet about bugs like these all the time, that's the most common outcome.

Are there examples of jail time for fraud happening for beingdishonest about sw product flaws?

Tech companies are not held liable by the justice department or any other federal org. It's against their interests because they now depend on these services to operate. Which is why you will never see Amazon, Google, or Microsoft sued in any damaging capacity for the obvious fraud they commit. That being fake products, reviews, promoting scams, antitrust, etc.

Be that as it may, which I have my doubts about since they are quite definitive about the problem being solved, I don't want a PR filter from the company that I would trust with my passwords.

What I want to know is have I been compromised or not, the PR saves face at further expense of users (if they truly have been compromised).

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.

Then why not say:

"We have identified and fixed bugs that could result in incorrect masterpassword use notifications being sent but we have not yet been able to determine which if any of the recent wave of notifications were caused by those bugs. We are still investigating the issue".

Instead of communicating clearly around a serious security incident they are using mealy mouthed PR speak which does nothing to improve their image.

You don't take into account that support told some of the customers that there was indeed a login attempt with valid password. I'm that sense it does sound a bit like backtracking. Now it's supposed to have only been a reporting error.

> it's either a complicated bug or there's more to the story.

I showed you pseudo-code which could trigger this issue. It was trivial code which could cause it in practice. Yet you claim it must be complicated or more to the story. I have no idea why you feel that classifying a request in a certain way must be caused by a complicated bug - very strange.

I think you're into FUD-mode now because even after being shown wrong, you continue to spread misinformation.

Also, you are referring to LP functionality which to my knowledge doesn't even exist, and when asked you say you don't know the software being discussed.

Very strange behavior by you.

combine that with lastpass' history of security mistakes, the people in on hn claiming that they didn't reuse the master password, and the press releases gas lighting their users, I'm not buying their story for a second.

Those all broke, that's how you know about them

What about “JFK”? What’s special about the fraction 9/11? Are we talking Epstein from welcome back kotter?

You sound paranoid.

My employer tried to move off them 2 years ago and didn't manage it.

The problem is the year subs. To avoid wasting money you need to do it at the end of a year, but you also need to get your users trained up before the switch. We hit a complication and ran out of time and so had to re-up.

I could see if you were a big company, trying to migrate a bunch of users and retrain them on a new password manager would be costly, there are probably admins out there looking for any reason not to make the move, but at this point, I think they have lost all credibility.

You have not provided any evidence or examples, just a “trust me”, which is essentially worthless. Also, there is a difference between a secret and a conspiracy. Secrets can survive for a long time, whereas history suggests that conspiracies rarely, if ever, succeed long term.

The military has a much bigger threat of prison for yourself than a company that the investors sue

They are indeed different. But if they were compromised, it doesn't mean that all employees there know. It would probably be a handful of engineers only. Maybe one day one of them will make a blog post with all the details, however, there are more incentives to keep their mouths shut than otherwise. If they come publicly about this, they will get a lot of unwanted exposure (which most people don't like), they will certainly lose their jobs, they will have to talk about that in every job interview they do, they will likely get sued due to NDA breaches, etc which will actually prevent them from being hireable in many places (specially security firms). So, it's much easier for these people, if they morally object this, to just quit, find another job and move on. They'll likely tell their friends and family not to use lastpass, but that will only travel so far.