Testing Zero Knowledge Against a Malicious Server

Researchers from ETH Zurich have published an academic paper analyzing the security architecture of cloud‑based password managers, including Dashlane.

We want to start by thanking the researchers for their work and for following a coordinated disclosure process. Independent scrutiny is essential for any security‑critical product. We worked directly with the team in advance of publication, reviewed their findings, and implemented fixes where appropriate.

Dashlane was included in this research because our client application source code is publicly available. We made that choice intentionally. Transparency makes it easier for third parties to inspect our design and hold us accountable. Security improves when systems are open to review.

If you’re looking for the bottom line:

Read on for more details.

The research evaluates password managers under a specific assumption: That the server infrastructure storing encrypted vaults is fully malicious, as if it has been fully compromised by an attacker.

This is a stronger model than the one traditionally assumed in many commercial systems. It asks a simple question: If the server can’t be trusted at all, what guarantees remain?

We believe this is a useful exercise. Password managers protect extremely sensitive data. It’s important for the industry to test claims against rigorous threat models.

The term “zero knowledge” doesn’t have a formal cryptographic definition. It’s an industry shorthand that has been used by password managers for more than a decade.

For us, it refers to an end‑to‑end encrypted architecture in which:

This is fundamentally different from more traditional architectures where providers have full access to user data.

One Dashlane‑specific issue identified in the paper is a cryptographic downgrade path in the browser extension due to legacy code.

Dashlane has fixed an issue that, if Dashlane’s servers were fully compromised, could have allowed a downgrade of the encryption model used to generate encryption keys and protect user vaults. This downgrade could result in the compromise of a weak or easily guessable Master Password, and the compromise of individual "downgraded" vault items.

This issue was the result of the allowed use of legacy cryptography. This legacy cryptography was supported by Dashlane in certain cases for backwards compatibility and migration flexibility.

Dashlane has removed support for this legacy cryptography, which means these downgrade attacks are no longer possible.

It’s important to note that the exploitation of this issue would require full compromise of a password manager’s servers, paired with a highly sophisticated threat actor able to execute cryptographic attacks, and an extremely significant window of time.

We’ve documented details of the issue in a security advisory.

The paper also discusses two broader architectural topics that aren’t new to the end‑to‑end encryption community.

When users share items, symmetric keys are encrypted with the recipient’s public keys. As with most server‑mediated end-to-end encrypted (E2EE) systems, this creates a structural dependency on the authenticity of the public key directory.

If an attacker were able to substitute the user’s public key with their own, the attacker could gain access to the contents of shared items encrypted with the malicious public key.

This is a known, industry‑wide challenge. We mitigate the risk today through hardened infrastructure and strict operational controls. While there’s no industry standard solution that provides strong guarantees without introducing usability or trust trade‑offs, we’re actively evaluating approaches such as Key Transparency to further strengthen our architecture.

For more details, see Section 7.5 Protection of Our Public Keys in our security documentation.

Dashlane’s synchronization model is transaction‑based. Encrypted transactions allow clients to reconstruct state across devices and enable historical recovery.

Because transaction keys are not uniquely bound to each transaction, a malicious server could potentially replay, reorder, or drop transactions.

This could result in inconsistent state or item loss. It doesn’t expose vault contents or leak encryption keys.

We explicitly accept this trade‑off because the same mechanism enables:

For more details, see Section 7.6 Transaction Replay and Vault Integrity in our security documentation.

This research reinforces several lessons:

We always welcome academic analysis because transparency, openness, and continuous improvement are critical to any security program.

Dashlane remains committed to continuous improvement of our zero‑knowledge architecture and values our collaboration with the researcher community.