Notifications
Clear all
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.
NHIMG editorial — based on content published by 1Password: analysis of ETH Zurich research on zero-knowledge password manager design
Questions worth separating out
Q: How should security teams evaluate zero-knowledge password managers?
A: Security teams should evaluate whether the system keeps decryption keys client-side, whether it can verify recipient keys, and whether recovery workflows preserve user-only control.
Q: Why do malicious-server assumptions matter for encrypted identity systems?
A: They matter because encryption alone does not solve identity provenance.
Q: What do teams get wrong about end-to-end encryption in password managers?
A: Teams often assume that end-to-end encryption removes the need to think about identity governance.
Practitioner guidance
- Review key provenance controls Map every workflow where the server mediates public-key distribution, recovery, or vault sharing, and verify how recipient authenticity is established before encryption occurs.
- Test hostile-server assumptions Include malicious-server scenarios in architecture reviews for any password manager or secrets platform that claims zero-knowledge protection.
- Separate custody from governance Document who owns the key, who can verify it, who can rotate it, and who can recover access when an account or vault is shared.
What's in the full article
1Password's full article covers the architectural detail this post intentionally leaves at a higher level:
- The paper discussion of zero-knowledge boundaries and why client-held keys change the threat model
- The public-key verification limitation and the vault key substitution scenario described under a malicious-server model
- The Security Design White Paper references that explain how SRP and local decryption are intended to work
- The account governance and automated provisioning context that sits around key verification and sharing
👉 Read 1Password's analysis of malicious-server testing for zero-knowledge password managers →
Zero-knowledge password managers: where malicious-server models fail?
Explore further
12/06/2026 5:57 am
Zero-knowledge changes the trust model, but it does not remove the identity problem. When a service cannot decrypt customer data, the decisive governance issue shifts to who controls the keys and how provenance is verified. That means the real risk is not ordinary server access, but whether the system can still prove identity and intent when the provider is untrusted. Practitioners should evaluate secrets platforms on custody, verification, and recovery, not on interface controls alone.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which helps explain why key provenance and trust boundaries remain weak in many environments.
A question worth separating out:
Q: How can organisations govern shared vaults without weakening zero-knowledge designs?
A: They should separate trust in stored data from trust in recipient identity and key provenance. Shared vault governance should require explicit verification of who controls the current key, how access is recovered, and what happens when accounts or devices change.
👉 Read our full editorial: Zero-knowledge password managers and malicious-server limits
