Zero-knowledge password managers and malicious-server limits

At a glance

What this is: This is an analysis of how zero-knowledge password managers behave under a fully malicious server model, with the key finding that the paper does not show new attack vectors beyond documented design limits.

Why it matters: It matters because IAM teams increasingly depend on encrypted identity systems for secrets and credential handling, and the real control boundary is key custody and provenance, not server-side permissioning alone.

👉 Read 1Password's analysis of malicious-server testing for zero-knowledge password managers

Context

Zero-knowledge architecture means the service provider cannot read customer data because decryption keys stay with the customer, not because the server is heavily permissioned. In identity terms, the security boundary is cryptographic custody, which makes key handling and key provenance the real governance problem for secrets and account data.

This article sits in the NHI and secrets-management space because password managers are part of the control plane for non-human credentials as much as they are a human-access tool. The practical question is not whether the server can be trusted in policy terms, but what breaks when the server is assumed to be malicious and the user must still retain exclusive control of the keys.

Key questions

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. The critical test is how the design behaves if the server is malicious, because that is where zero-knowledge claims are either proven or weakened.

Q: Why do malicious-server assumptions matter for encrypted identity systems?

A: They matter because encryption alone does not solve identity provenance. If the server can substitute keys, manipulate distribution, or interfere with recovery, the system may still protect ciphertext while failing to prove that data was encrypted for the intended recipient.

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. In practice, it shifts the problem to key custody, verification, sharing, and recovery, which are governance functions that still need clear ownership and review.

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.

Technical breakdown

Zero-knowledge architecture and local key custody

Zero-knowledge design keeps data encrypted so that the provider never sees usable plaintext. In this model, the user password, Secret Key, and encrypted vault data must all be present before decryption can occur, and the provider cannot reconstruct the vault on its own. Secure Remote Password is relevant because it prevents password-derived secrets from being transmitted in a form that a server capture could reuse. The architectural point is that access control is not the primary defence. Key custody, client-side decryption, and resistance to server compromise are the real security primitives.

Practical implication: Practitioners should treat client-held keys and recovery paths as the core trust boundary, not server permissions.

Public-key verification and vault key substitution

The paper’s important architectural concern is not a new exploit class but the difficulty of proving that an encrypted public key belongs to the intended recipient when the server mediates distribution. If a malicious server can substitute a dishonest public key, it can cause users to encrypt data to the wrong key without breaking end-to-end encryption itself. That is a provenance problem, not a brute-force problem. It shows why key verification and recipient authenticity remain hard even when transport and storage are already encrypted.

Practical implication: Teams should scrutinise how recipient keys are verified during provisioning, sharing, and recovery workflows.

Why malicious-server testing matters for password managers

A malicious-server model is useful because it tests whether the design still protects secrets when the provider is no longer trustworthy. That is a stronger test than ordinary access-control review, since it examines whether the cryptographic design can survive an adversarial infrastructure layer. For password managers, the main question is not whether the server can read vault contents, but whether architecture still preserves user-only control under hostile conditions. This is the right lens for evaluating secrets systems that claim end-to-end protection.

Practical implication: Security review should include hostile-server assumptions whenever a product claims zero-knowledge or end-to-end encrypted handling.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Server-mediated key distribution without strong provenance guarantees is the named failure mode here. That pattern is already visible in the paper’s discussion of public-key verification and vault-key substitution. If the server can hand out the wrong key, end-to-end encryption remains intact while confidentiality still fails in practice. The implication is that encrypted identity systems can be architecturally sound and still expose users to trust-substitution problems.

Zero-knowledge architecture is a control boundary, not a complete governance model. The architecture can prevent the provider from reading vault contents, but it cannot by itself answer who can verify keys, who can recover access, or how key rotation is governed over time. That separation matters for both human identities and NHI credentials because the same secrets layer increasingly supports account access, shared vaults, and automated workflows. Practitioners should treat key verification as an identity governance requirement, not a product feature.

Malicious-server analysis is most useful when it tests assumptions, not marketing claims. The paper reinforces a broader industry reality: encrypted systems can still face structural limits around authentication of recipients, shared key management, and account governance. Those limits do not invalidate the model, but they do define where controls stop. The field needs more honest language about what end-to-end encryption protects and what it leaves unresolved.

Key provenance, not just key possession, is the governance concept this article sharpens. Possessing a key is not enough if the system cannot prove that the key belongs to the intended recipient at the moment of use. That distinction is central to secrets management, account provisioning, and automated access workflows. Practitioners should design governance around proof of origin as well as encryption strength.

From our research:

• 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.
• That confidence gap is why NHI Lifecycle Management Guide matters when secrets, shared access, and recovery workflows need governance beyond encryption claims.

What this signals

Key provenance is becoming the deciding factor in secrets governance. As encrypted systems expand across human and non-human access, the control question shifts from whether data is encrypted to whether the intended recipient can be verified at the moment of use. That is where many programmes will find their current operating model incomplete.

The practical signal for identity teams is that recovery, sharing, and provisioning workflows now deserve the same scrutiny as authentication. If those paths are not governed, zero-knowledge becomes a storage property rather than an operational security boundary.

The governance boundary is moving from access restriction to cryptographic assurance, which means teams should align vault design with lifecycle controls and evidence of key provenance.

For practitioners

• 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. Pay particular attention to any process where the user cannot independently confirm the key they are encrypting to.
• Test hostile-server assumptions Include malicious-server scenarios in architecture reviews for any password manager or secrets platform that claims zero-knowledge protection. Validate what still remains protected when the backend is treated as compromised and check whether the model depends on undocumented trust in server-side key handling.
• 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. Use that control map to identify where identity governance ends and cryptographic assurance begins.
• Align shared vault design with account governance Treat shared vaults, provisioning, and account lifecycle controls as one governance chain so that access changes do not outpace verification. Where automated workflows exist, require explicit evidence that the intended recipient and the current key remain aligned.

Key takeaways

• Zero-knowledge design protects data by keeping keys with the customer, but it does not eliminate the need to verify who receives those keys.
• The main architectural risk discussed here is key substitution through server-mediated distribution, which can preserve encryption while breaking confidentiality in practice.
• Identity teams should govern secrets platforms by custody, provenance, and recovery workflows, not by server-side permission models alone.

Key terms

• Zero-knowledge architecture: A zero-knowledge architecture is a design in which the service provider cannot access customer plaintext because decryption happens only on the customer side. The model depends on local key custody and strong cryptographic boundaries, not on trusting the provider’s operational permissions.
• Public-key verification: Public-key verification is the process of confirming that an encryption key really belongs to the intended recipient before data is encrypted to it. In managed identity systems, weak verification creates a provenance problem even when transport and storage encryption are technically sound.
• Vault key substitution: Vault key substitution is a failure mode in which a malicious or compromised server supplies the wrong public key, causing a user to encrypt data to an unintended recipient. The ciphertext remains encrypted, but confidentiality fails because trust in key provenance has been broken.
• Key provenance: Key provenance is the evidence that shows where a key came from, who controls it, and whether it belongs to the identity it claims to represent. For secrets governance, provenance matters as much as possession because the wrong key can still satisfy the encryption workflow.

Deepen your knowledge

Key provenance and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is reviewing encrypted secrets or password-manager controls, the course provides a useful baseline for governance design.

This post draws on content published by 1Password: analysis of ETH Zurich research on zero-knowledge password manager design. Read the original.