Unless they kept it a secret (and they haven't if they've "let affected customers know privately"), Troy, by refraining from posting it, would, in a single act, lose all the good will and respect and credibility he's spent YEARS building up by acting professionally, honorably, and highly competently.

So, yeah, I think it's quite safe to be confident he wouldn't do that.

It would be too much of a double edged sword that I'm sure Troy must have realized.

Oh, I'm sure he'll post it. 1Password is software that falls into the same interest area as those who care about password disclosures, hence this probably being a good partnership.

The moment 1Password is compromised and Troy "nothing to see here"'s it? People would turn on both products very quickly because they'd find out about the former as private users and when the latter didn't disclose it, it would lose credibility.

1Password is a proprietary walled garden.

But who will leak?

What is the question? Are you asking who breached 1Password? Some hacker, just like any breach.

Are you asking who tell the general public? Some hacker, or some chain of associates, just like any breach. HIBP only stores breaches that have previously been made public. So for for HIBP to "ignore" a breach, the breach has to already be public, so there will be news organizations covering the breach if it's big.

Lets say it did happen. And now they keep it quiet.

This DB would end up on a darknet auction somewhere, and that's where things get "fun". Now, people can talk about this auction and all the really bad ramifications of both parties hiding it.

Worse yet, I could see someone waiting a month, and them leaking a DB that's fake and encrypting and dumping on the Darknet. The goal there is slander.. It doesn't have to happen for the damage to be done.

I'm not sure your scenario actually makes sense, even beyond the trust destruction issues others have highlighted.

>Let's say 1Password somehow got breached, and customer vault passwords exfiltrated and posted online.

First, 1Pass is not LastPass. Even their cloud service is optional (I don't use it for one), and it still operates end-to-end encrypted through a native client doesn't it? At least for those clients AgileBits simply doesn't have this information at all so there's nothing to breach. Unless by "breached" you meant "hacked so badly that a copy of the client with malware got signed and made it through app store review." But an infected client is much more easily noticed by massive numbers of people, making secrecy even more pointless then it'd be otherwise (which would still be pointless because such a breach would be obvious instantly if it was put to use).

Second and more importantly, one of the entire fundamental points of password managers isn't merely to not get breached, it's that if they do there's an orderly way to go through and change every single password to something new and random. Yes, it'd be an irritation for a whole vault, and if it happened repeatedly it'd be reason to move to something else, but the only possible way for it to escalate from a minor problem to a huge one would be for notification to be delayed. I don't see how it wouldn't be in AgileBit's direct financial interest to come clean as instantly and rapidly as possible, which would minimize both customer impact and liability. With word out operators of sensitive services could also know to be on higher alert and/or issue mandatorh resets. This last part would apply to LastPass or any other such service too fwiw.

Granted I'd hope such a thing, or even the possibility, would motivate an industry push for standardized password/username interaction APIs. There's no technical reason that cycling every single password you've got shouldn't be at least a mostly automatable operation. It'd be better still if passwords were done away with entire in favor of certs but might as well keep improving the current pile of hacks if that's the best we can manage piecemeal I guess.

I guess time will tell, but from what I’ve seen I don’t think they’d hold back.

There was a company which literally handed their database to Troy after a breach so everyone would be on equal footing to the attackers.

Which?

Several. It was covered in another post by troy hunt: https://www.troyhunt.com/the-legitimisation-of-have-i-been-p...

Troy is hobbying in a really gray area, where potentially the possession of massive amounts of passwords from breaches could be a legal liability, and he's trying to do it in a way that benefits the average user and business. To do that, he needs to get and keep their trust.

I've pointed a few folks to his site and their very first question, every time, is some variation of, "you mean you want me to type my password into this dude's site?"

So haveibeenpwned is basically relying on Troy's reputation alone, which he alludes to in pretty much all of his blog posts about it.

It's hard for me to imagine him not publishing everything he learned about a 1password breach.

> I've pointed a few folks to his site and their very first question, every time, is some variation of, "you mean you want me to type my password into this dude's site?"

And this is why the v2 API design is important.[0]

Instead of sending a password to an external site, you hash the password locally with SHA1, and send in just the first five hex digits. In return you get a list of hash suffixes of known-broken passwords. You get to verify locally whether the password is known, without the password ever being transmitted.

The API is so simple to use that one of our engineers implemented and deployed a HIBP check roundtrip in less than a day. Usually a functional change in authentication path would stay in review for somewhat longer (due to people wanting to make very sure we don't mess it up), but the new API is really straightforward to reason about. It was trivial for reviewers to see that we couldn't leak information by accident.[ß]

0: https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

ß: Technically it would be possible for Troy and Cloudflare to correlate the number of times a particular blob is requested and the "times found" count in the list of suffixes. But because we reject known-broken passwords, the only real information that gets exposed is the number of times users attempt to choose passwords that may have higher-than-usual incident counts.

I for one will certainly not type any real-world password in Troy's site and this has nothing to do with Troy's reputation.

Entering your password on this site effectively reduces the strength of your encryption (or whatever you use the password for) to the strength of the SSL encryption used, plus all possible side channel attacks you can mount against browsers and network protocols like DNS, plus the security or insecurity of Troy's own machines, and the guy is already a viable target for dozens of intelligence agencies. Note that a man-in-the-middle attack on this site is almost impossible to detect and there is no way for you to tell whether Troy Hunt's servers and developer machines are compromised or not.

So in a nutshell, it's a big No No. But it makes sense for a company like 1Password to cooperate with him, since these companies are in the business of storing all your passwords "in the cloud" anyway.

I would guesstimate that around 90% of all passwords these days belong to web-based services, for which everything you just said is still true, with the exception that they aren't run by Troy Hunt. There is an extraordinarily long tail of sites for which "run by Troy Hunt" would be a huge improvement.

Actually I bet my guesstimate is way too low.

Furthermore: if you're using unique random passwords anyway, then there's no sense in checking them against HIBP, and if you're not, then punching them into HIBP is how I try to convince people that they should be.

So glad I signed up for client-side 1password back when it was still available.

I'm still baffled that they decided to sunset it.

Is it completely gone? I thought it could be found by posting on the forums or searching deep within the site (not easy, but was possible).

I for one have moved out of 1Password on the desktop and use other clients. I don't mind paying for software, but companies using dark patterns like hiding purchase options intentionally don't deserve my money.

1Password costs 36 USD/year. Lastpass costs 24 USD/year (from 12 USD/year since they got bought by LogMeIn). Bitwarden costs 12 USD/year (if you use 2FA), and Bitwarden is open source. Easy choice if you ask me.

That doesn't make sense. People don't learn about breaches from a single place. What could 1password possibly gain from this, even if they could somehow do it?

This isn't about breach detection, it's more about "which of my many pwds that I use has already been doxxed and likely in a try first dictionary"?

Read the concern in the parent to what you're responding to. Essentially, "with this partnership, is Troy likely to hand wave if 1Password's logins are breached?" and the credibility concerns that this partnership may create.

PR management is what this is about. I wouldn't put it past a company to not do that when the situation arises.

Not going to happen. The moment that leaked out both parties would lose all trust from the industry. That's a hell of a hypothetical question though.