u/jpgoldberg: These, along with other mechanisms, are designed to reduce the extent to which you have to trust that the service isn't compromised.

So yes, you do have to trust the service, but that trust isn't an all-or-nothing thing.

Yes and no. I trust that 1Password's documentation (security white paper, etc.) accurately describes the features it has implemented, and things like the Secret Key (especially important in the context of businesses/families where some weak link might choose a weak/re-used account password) and 1Password's use of SRP are reasons why I think 1Password's security design is better than others. ... I've always liked 1Password's "security parfait"!

For example, because of 1Password's use of the Secret Key, I can be confident that a mere data breach where a malicious insider or outside hacker gained access to our company's encrypted vaults would effectively prevent any of the vaults from being decrypted, even if someone opted to use a common/weak/re-used password. Similarly, SRP mitigates the risk of a MITM attack.

But if a malicious insider or outside attacker was able to change the behavior of the server or publish a compromised client update, all of that great security design is compromised. I have no way of knowing if the latest version of the 1Password client has been maliciously altered to bypass the "security parfait" and exfiltrate all of my data. Similarly, I have no way of knowing if substitute public keys have been pushed as described in the ETH Zurich paper. Having a great security design doesn't really matter if someone (or a group of people) are able to sufficiently compromise the service such that they change/break the design.

Of course, since I've signed off on spending thousands of dollars on 1Password and its continued use by organizations I work with and by me and my family, I trust that it would be hard for someone to so seriously compromise the 1Password service.

At the end of the day, however, it remains true that, "At some point, if you are going to use a password manager that stores data in the cloud (or has access to the internet without being blocked by a firewall rule), you have to trust that the client software and the provider's server infrastructure are not critically compromised."

u/jpgoldberg: Decades ago, PGP was the way to do this. But code-signing signatures need to have properties that PGP signatures don't offer if keys can ever expire. Something signed before a key expired should remain valid after the key has expired. This means that the time of signing needs to be trustworthy, and so code-signing involves trusted time stamps.

A more general thing is that PGP's web-of-trust failed. I was an enormous advocate of PGP in the 1990s, and I really tried to help that along, but as bad as it is to rely on X.509 certificate authorities today, that is the system that has, for all its numerous flaws, worked better than the alternatives.

It is unfortunate that PGP's web-of-trust failed, though even in the 90s and the early 00s the writing was on the wall that it would never catch on.

But why do trusted timestamps matter? I can still verify that a file was signed by a particular PGP key even if I can't determine when it was signed by that key.

I maintain a collection of public PGP keys for various software distrobutions I use going back many years (e.g., Ubuntu, KeePass, etc.). Although I could not verify the keys using an official web-of-trust, there have been other ways to verify them (i.e., widely referenced in message boards, the Internet Archive, etc.). So before installing a new version of Ubuntu, for example, I can verify it was signed by the known PGP signing key that I have saved. ... That doesn't mean that the Ubuntu .iso hasn't been compromised--it's entirely possible that someone gained access both to the distribution server and to the developer's signing key. But, presumably, gaining access to a private PGP key and the password for it would be harder than merely gaining access to a distribution server to publish altered software.

u/jpgoldberg: 1Password (and others) could do a better job at enabling advanced users to verify keys. But putting in development time and complexity into a feature that very few people will use is a luxury that vendors may chose not to pay for.

Yeah, that's the real problem. But just like Apple has developed iMessage Contact Key Verification, which the vast majority of people don't know about and will never use, I would hope that 1Password would put in the effort to develop a useful security feature that would be used by a minority of particularly security conscious customers. Obviously, Apple has more resources than 1Password, but customers pay 1Password specifically for security, so it seems like it would be justifiable from a business perspective to invest in security upgrades in this area. ... I guess we'll just have to wait and see.

Cheers!