ETH Zürich paper concerns

I also have concerns with this paper.

I don't see this claim in the 1Password security white paper, but the implied claims when using an E2EE password manager is you do not have to trust the server.

This is actually not true generally, because we need to trust 1Password to deliver a non malicious version of the client application, otherwise they could easily exfiltrate decrypted vault data to wherever they need. I personally trust 1Password on the software supply chain side of things. But this is not what the paper is addressing anyway.

The paper addresses a malicious server, which could be 1Password itself, in that the ideal goal of E2EE password manager is that your vault data should never be revealed to anyone but the client. In Appendix D which discusses an attack that 1Password has already intimated in their security whitepaper is that of a vault substitution attack. The underlying problem is that of shared vaults where there's many members and each using public key encryption to share vault items to each other, without having an anchor of trust for each public key, which means a middle-man (1Password server, or a malicious server) can substitute public keys for other members with their own when data is encrypted to them, which allows the server to peek at the data.

If I understand the mitigation presented in the paper, all that is needed is binding the vault encryption key that is shared to the other users, with a digital signature that it came from me (Alice). I don't know if this mitigation is as simple as it sounds, but if it is, I would hope the architects and developers of 1P commit to at least this mitigation.

Otherwise, 1Password has done wonderfully in its security posture as shown by the paper. By simply using a secret key to mask the unlock password they've warded off an entire class of attacks that are plaguing the other password managers, and by properly encrypting vault data with AES-GCM and the entirety of the vault data/items without leaking metadata, there's even no issue of slight weakness it seems.

But the importance of the paper is not to attack password managers. It is to find a threat model that stands up to the marketing claims of companies selling these password manager services, and have a benchmark when it comes to ideal security.

Edit:

I had some further reflection spending a bit more time considering the trust model. In the paper the attacker has full control over the 1P servers that interact with the client.

This actually gives me some confidence and I don't think it is emphasised in the paper why the scenario is too far fetched.

The only way an attacker can have a client talk with its malicious servers is if (1) they compromise the client pointing to their attacker run servers or (2) either 1P turns on their users or a breach of their servers happen either through a rogue employee or external attacker.

Focusing on (1), the problem that an attacker faces in running the 1P infrastructure is they need the authenticator that is used for SRP (Secure Remote Password Protocol) which is used to verify the combined/mixed password and secret key, without ever exchanging it. So (1) would fall flat on its face. But the reality is, if an attacker could compromise the client, then an attacker would simplify deliver a tainted client that siphons all the decrypted vault data to their own attacker run servers. This is of course a threat that applies to all password managers, whether local or cloud based, one of the scariest threats, but also probably somewhat hard to pull off as it usually implies a local compromise. This would be in the realm of info-stealer malware territory.

This really just leaves the issue of (2) where 1P either turns on its users or the infrastructure is breached. I think ultimately such an attack if performed on a user could exfiltrate data from a shared vault or a newly created vault, but if there is a substitution attack on an existing vault it'll probably cause alarm bells going off for the user. So such a breach would probably be detected fairly swiftly. But again, if 1P infrastructure was breached, I think the crown jewels would be their download/update servers where an attacker would inject a tainted client and siphon data as in the scenario I just mentioned above.

It is not ideal that we can't place full trust in 1P knowing that if the servers are compromised then there is potential for sensitive data to be leaked. But there is a worse and easier threat that we could easily succumb to and that would be that of a supply of a tainted 1P client that would exfil data.