Topic starter
10/06/2026 11:40 pm
TL;DR: ETH Zurich researchers tested password managers against a fully malicious server model and 1Password says the paper does not reveal new attack vectors beyond documented architectural limits, highlighting how zero-knowledge designs depend on local keys, public-key provenance, and end-to-end encryption. The broader lesson is that trust boundaries in encrypted identity systems are architectural, not just policy-based.
Editorial analysis by NHI Mgmt Group, based on content published by 1Password: “Zero knowledge vs. a malicious server: A look at ETH Zurich’s research”.
Key questions
Q: What fails in a zero-knowledge password manager when the server is malicious?
A: The failure is not automatic decryption of vaults.
Q: Why does public-key verification matter in encrypted identity systems?
A: Because encryption is only as trustworthy as the key you encrypt to.
Q: How should security teams evaluate zero-knowledge claims in password managers?
A: They should verify where encryption happens, who holds the keys, and whether the provider can ever access plaintext during normal operation or cloud processing.
Practitioner guidance
- Map the cryptographic trust boundary Document where decryption depends on client-held keys versus server-held metadata, and make that boundary explicit in your identity risk model.
- Verify public-key provenance Require a way to confirm that encryption targets belong to the intended recipient before relying on server-mediated key distribution for sensitive vault data.
- Review group-encryption assumptions Check whether shared vault or team-key workflows still preserve trust when user-owned keys rotate over time or when a provider cannot be assumed honest.
Bottom line: Zero-knowledge password managers shift the security boundary from server permissions to client-held keys and verifiable key provenance.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 18 hours ago by NHI Mgmt Group
12/06/2026 5:57 am
Zero-knowledge security is a key-provenance problem, not a permission problem: The article reinforces that server-side access controls do not define the actual trust boundary in end-to-end encrypted identity systems. If the provider never holds the keys, then the real question is whether clients can verify where those keys came from and whether they were substituted. Practitioners should evaluate encrypted identity products on provenance guarantees, not on administrative access narratives.
A question worth separating out:
Q: What is the difference between server-side access control and cryptographic trust?
A: Server-side access control limits what administrators can do inside the service, while cryptographic trust determines whether the service can ever read or reroute the protected data. In zero-knowledge architectures, cryptography defines the hard boundary. Policy can reduce exposure, but it cannot replace client-held keys or key provenance guarantees.
👉 Read our full editorial: Zero-knowledge password managers and malicious-server limits
This post was modified 18 hours ago by NHI Mgmt Group