Password Manager Zero Knowledge Claims Under Fire: What You Need to Know [2025]

You trust your password manager with everything. Your banking credentials, cryptocurrency wallets, payment cards, social media accounts, sensitive documents. Everything.

And that trust is built on a single, powerful promise: zero-knowledge architecture. This is the idea that even if someone breaks into the password manager's servers—hackers, malicious employees, governments—they still can't touch your vault. The encryption is so airtight, so mathematically secure, that your data might as well be locked in a titanium safe buried underground.

Bitwarden says "not even the team at Bitwarden can read your data." Dashlane claims that "malicious actors can't steal the information, even if Dashlane's servers are compromised." LastPass asserts that "no one can access the data stored in your LastPass vault, except you."

These aren't small claims. They're the bedrock of the entire password manager industry. With roughly 94 million US adults using password managers—or about 36% of the adult population—and 60 million people relying on just Bitwarden, Dashlane, and LastPass combined, these promises matter enormously.

But here's the problem: new research from security experts at ETH Zurich and USI Lugano shows that these promises aren't always true. When certain features are enabled—account recovery, shared vaults, group organization—the zero-knowledge armor cracks. Researchers have identified specific, exploitable vulnerabilities that allow attackers with server access to read, modify, or steal entire vaults.

This isn't theoretical. It's not a minor edge case. And it fundamentally changes how you should think about password manager security.

Let's dig into what researchers actually found, how these attacks work, and what you can do about it right now.

TL; DR

Zero-knowledge claims aren't universal: Password managers are only actually zero-knowledge when specific account recovery and sharing features are disabled.
Key recovery is the weakest link: Account recovery mechanisms designed to help users regain access have exploitable encryption flaws that attackers can weaponize.
Sharing vaults creates vulnerabilities: When you share passwords with family members or team members, the encryption scheme changes in ways that expose plaintext data to server-side attackers.
Multiple password managers affected: Bitwarden, Dashlane, LastPass, 1Password, and others all have variants of these same fundamental issues.
The fix requires tradeoffs: Making password managers truly zero-knowledge means losing convenient features like automatic account recovery and vault sharing.

The Promise: Zero-Knowledge Encryption Explained

First, let's get clear on what zero-knowledge actually means. And I mean the real definition, not the marketing version.

Zero-knowledge architecture is built on the idea of end-to-end encryption. Your passwords are encrypted on your device using your master password as the encryption key. This encrypted blob—your vault—is then sent to the password manager's servers. The servers store this blob, back it up, replicate it across data centers, but they never decrypt it. They can't. They don't have the key.

Think of it like this: you have a safe with a combination only you know. The password manager company agrees to store your safe in their warehouse. They keep the warehouse secure, they protect it from thieves, they insure it against disasters. But they don't have the combination to your safe. Nobody working there does. If a burglar breaks in, they get the safe, but it's worthless without the combination.

When implemented correctly, zero-knowledge means the password manager service is mathematically incapable of accessing your data. Not unwilling. Incapable. There is no backdoor, no master key, no secret decryption method. Even if law enforcement showed up with a warrant, or if a state-level adversary compromised the entire infrastructure, your vault would still be safe.

This is why zero-knowledge became the industry standard. After LastPass suffered a major breach in 2022 where hackers stole massive amounts of customer data, users got a wake-up call about the risks of password manager hacks. Zero-knowledge became the confidence builder: "Don't worry about our security, because even if we get compromised, the attackers still can't read your passwords."

It sounds airtight. And for the basic case—a user with a single account, no recovery option enabled, no shared vaults—it actually is.

But password managers aren't simple anymore. They have features. Lots of features.

The Reality: What Researchers Actually Found

Last year, researchers from ETH Zurich and USI Lugano conducted a detailed cryptographic analysis of three of the most popular password managers: Bitwarden, Dashlane, and LastPass. They reverse-engineered the applications, studied the code, ran security audits, and documented what they found.

What they found was troubling.

The researchers identified multiple vulnerabilities in the zero-knowledge implementations. Some allow attackers to read entire vaults. Others allow attackers to modify vault contents. Still others weaken the encryption to the point where ciphertext can be converted back to plaintext.

In some cases, the same attackers could "infect" related accounts in a worm-like fashion, spreading from one vault to another through shared group keys.

The most damaging part? The researchers found that multiple other password managers likely suffer from the same flaws. They couldn't analyze 1Password as thoroughly due to access limitations, but they identified the same vulnerability pattern in its code.

This isn't about sloppy implementation either. All three password managers had undergone multiple professional security audits. Academic researchers have published over a decade of research on password manager security. Yet these vulnerabilities hadn't been caught until now.

The researchers said it best: "The vulnerabilities that we describe are numerous but mostly not deep in a technical sense. Yet they were apparently not found before, despite more than a decade of academic research on password managers and the existence of multiple audits of the three products we studied."

What makes this particularly striking is that the vulnerabilities aren't hidden behind complex cryptographic tricks. They're in the logic of how features work. In how the encryption keys flow between client and server. In how security assumptions are made about data that isn't actually protected.

How Account Recovery Became the Weak Link

Here's where things get interesting. The vulnerabilities mostly cluster around one specific feature: account recovery.

Account recovery is a convenience feature. You forget your master password, you lose access to your account, you panic. Normally you're completely locked out—nobody can help you, because if they could, zero-knowledge would be compromised. But password managers offer a workaround: you can enable account recovery, which creates a special encrypted backup of your vault encryption key. If you forget your master password, an admin (or the company itself) can use this backup to restore your access.

This is genuinely useful. Master passwords are supposed to be unique, complex, unmemorable strings. People do forget them. Account recovery prevents the nightmare scenario of total permanent lockout.

But the way password managers implemented account recovery creates a cryptographic liability.

Here's the basic mechanism: When you enable recovery, the password manager creates a recovery key. This recovery key is encrypted using a special key that's held by the organization admin or the company. The encrypted recovery key is stored on the server.

If you forget your password, you contact support. They verify your identity. Then they use their key to decrypt your recovery key, which is then used to restore your vault access.

The problem: this recovery key is itself encrypted with a public key, and the entire process of handling that public key has integrity gaps.

Specifically, during account enrollment in a family or organization, the new member's client requests the organization's public key from the server. The server sends it, the client encrypts the recovery key with it, and sends the ciphertext back. The vulnerability is that this exchange is never integrity-checked. The server never signs the public key. The client never verifies the signature.

An attacker controlling the server can exploit this by substituting their own public key. When the client encrypts the recovery key with the attacker's key, the attacker can decrypt it using their private key. Suddenly, the attacker can perform account recovery on behalf of the user. Once they recover the account, they have access to the entire vault.

And here's the cascade effect: the attacker now has the group's symmetric key. This key is shared among all group members. If any other organizations this user belongs to also have recovery enabled, the attacker can compromise all of them. It spreads like malware.

In a group with overlapping members across multiple organizations, a single compromised account becomes a beachhead for accessing dozens of vaults.

The Key Rotation Attack: When Changing Your Password Breaks Your Security

Bitwarden includes a feature that sounds like it should be secure: key rotation. If you suspect your master password has been compromised, you can trigger a key rotation that generates a completely new encryption key for your vault. All your existing passwords get re-encrypted with this new key.

It's a reasonable feature. But researchers found that when account recovery is enabled, the key rotation process creates a window of vulnerability.

Here's the mechanism: During key rotation, the password manager needs to re-encrypt the recovery ciphertext (that recovery key we discussed earlier) using the new vault key. To do this, it needs the organization's public key again. That public key is requested from the server during the rotation process.

If an attacker controls the server, they can do the same substitution attack we described before. They replace the legitimate public key with their own. The client, which still isn't integrity-checking the key, accepts it. The recovery ciphertext gets re-encrypted with the attacker's key. The attacker now has a new opportunity to decrypt it using their private key.

What makes this particularly nasty: the recovery ciphertext is generated fresh with each key rotation, so it's a moving target. But if the rotation happens while recovery is enabled, the target is there, and the attacker can hit it.

This means that doing the right thing—rotating your key when you suspect a compromise—actually creates a new vulnerability if recovery is enabled. The security feature undermines itself.

Vault sharing is one of password managers' best features. You share your Netflix password with your partner. You share your company's GitHub credentials with your development team. You share your family's streaming service logins with your parents.

This is genuinely useful and impossible to avoid if you want to use password managers in any collaborative context.

But sharing changes the encryption model. And that's where researchers found significant vulnerabilities in Dashlane.

When you share vault items with other users, the encryption scheme has to shift. Instead of encrypting with a personal key that only you know, shared items are encrypted with a group key that multiple people have access to. This makes logical sense—everyone in the group needs to decrypt the items.

But here's the problem: the way Dashlane implemented group encryption means that if an attacker can read the group key from the server and control the server, they can read all shared vault items. That violates zero-knowledge. The attacker becomes a group member in effect, able to decrypt things they shouldn't.

The issue stems from how the group key itself is distributed and stored. In a proper implementation, the group key would be encrypted in a way that only authorized members could decrypt. But in Dashlane's implementation, there's a window where the unencrypted group key is accessible to server-side attackers.

It's not a complete vault theft like with Bitwarden, but it's a serious break in the zero-knowledge promise. Shared passwords are particularly valuable to attackers, because they're often the most important ones: business credentials, family financial accounts, shared administrative access.

LastPass Legacy Versions and Backward Compatibility Problems

LastPass took a different route toward the same problem. The vulnerability here centers on legacy version support.

Password manager clients get updated constantly. New features, security patches, performance improvements. But not everyone updates immediately. Some users stick with old versions. LastPass supports this by maintaining backward compatibility with clients that are several versions old.

The problem: older versions of LastPass had weaker encryption schemes. When the researchers analyzed the code, they found that the server can detect which version of the client a user is connecting from, and can adjust how it handles encryption accordingly.

An attacker with server control can force a user to decrypt their vault using the weaker legacy encryption scheme. This is done by manipulating the version information that the server sends to the client, or by directly downgrading the encryption protocol.

Once the vault is decrypted with the weaker scheme, it becomes vulnerable to cryptographic attacks that wouldn't work against the newer encryption. The attacker can recover plaintext passwords from the ciphertext.

This is particularly problematic for LastPass because the vulnerability affects existing vaults retroactively. You don't need a user to create a new account or enable a new feature. An attacker can compromise an old, existing vault that's been sitting on the server for years by forcing it through legacy decryption.

Understanding the Cryptographic Weaknesses

All of these attacks exploit one fundamental cryptographic principle: integrity checks are missing.

In modern cryptography, you don't just encrypt data. You also authenticate it using a message authentication code (MAC). The idea is simple: when you send encrypted data, you include a mathematical proof that the data hasn't been tampered with.

The sender computes a MAC based on a secret key that only they know. They send both the ciphertext and the MAC. The receiver computes the same MAC using the same secret key, and verifies it matches. If an attacker modifies the ciphertext, the MAC won't match, and the receiver knows something is wrong.

This prevents attacks like the public key substitution attack we described. If the public key was authenticated with a signature, the attacker's fake key would fail verification.

But in many of these password manager implementations, the cryptographic steps aren't authenticated. The encryption happens, but there's no MAC. The client receives encrypted data from the server without any proof that it hasn't been modified. This creates an opening.

The researchers actually devised a mathematical framework to describe these gaps. They called it encryption without authentication, and showed how it can be exploited to perform various attacks ranging from complete vault theft to partial plaintext recovery.

What's surprising is that this is solved computer science. Authenticated encryption has been standard cryptographic practice for years. The NIST standard recommends it for all encrypted communications. The fact that major password managers missed it suggests that the security review process wasn't rigorous enough on cryptographic assumptions.

The Worm-Like Infection Pattern: How One Breach Spreads

One of the most disturbing findings was how these vulnerabilities chain together. Researchers demonstrated what they called a "worm-like infection" pattern.

Imagine you're part of three different organizations using Bitwarden:

Your work company (Company A)
A freelance collective you work with (Company B)
A family group managing shared finances (Family Group C)

Each organization has account recovery enabled. There's overlap in members—maybe your colleague is also in the freelance collective. Maybe a family member is in the work group.

An attacker compromises Company A's organization using the public key substitution attack. They now have the recovery keys for Company A members, including your account.

But you're also a member of Company B. When the attacker recovers your account in Company A, they get all the group keys you have access to—including the Company B group key.

Now the attacker is effectively a member of Company B. They can use the same attack to compromise other users in Company B.

Some of those users might also be in Family Group C. Suddenly the attacker is spreading through Family Group C too.

The attackers don't need to compromise each organization separately. They can compromise once, then laterally move through shared group keys to compromise related organizations automatically. The paper describes this as a chain reaction that can "infect" dozens of vaults with minimal additional effort.

Which Password Managers Are Vulnerable?

The research focused on three password managers: Bitwarden, Dashlane, and LastPass.

Bitwarden had the most severe vulnerabilities, with complete vault theft possible under certain conditions.

LastPass had similar vault theft risks, plus the legacy version vulnerability.

Dashlane had more limited vulnerabilities but still serious ones affecting shared vault items.

The researchers also indicated they found similar vulnerability patterns in 1Password, though they couldn't analyze it as thoroughly. They specifically said they were "at liberty to name" 1Password as a likely victim of the same flaws.

Beyond those, the researchers suggested that "almost all the password managers" likely suffer from the same types of vulnerabilities. The underlying cryptographic mistakes—missing authentication checks, improper key distribution, unprotected recovery mechanisms—are common patterns in how password managers were designed.

The exception? Researchers didn't identify any major password manager that was completely free of these issues when features like account recovery and vault sharing were enabled.

This isn't meant as criticism of individual companies. It's meant as a wake-up call that the entire password manager ecosystem has been making similar cryptographic assumptions, and those assumptions are weaker than marketing claims suggest.

What Actually Needs to Happen: The Architecture Problem

The researchers were clear about the root cause: the zero-knowledge promise is only maintained for very basic password manager usage. The moment you add convenience features—account recovery, vault sharing, group management—the mathematics changes.

There are ways to implement these features securely. You could have account recovery that doesn't involve server-side decryption. You could have vault sharing that uses more sophisticated key derivation. You could have organizational features that maintain cryptographic guarantees.

But these solutions require tradeoffs. Account recovery without server knowledge requires keeping encrypted backup copies that you manage yourself, which defeats the purpose of automatic recovery. Vault sharing with strong cryptographic guarantees requires much more complex key management, which slows down the user experience.

Essentially, password managers face a choice: be truly zero-knowledge but inconvenient, or be convenient but compromise on cryptographic guarantees.

They've chosen convenience. And they haven't been transparent about that tradeoff.

The marketing says "zero-knowledge." The reality is "zero-knowledge except when features are enabled."

A more honest claim would be: "We implement end-to-end encryption, which protects your data if our servers are breached. However, features like account recovery and vault sharing require us to have partial access to cryptographic keys, which reduces but doesn't eliminate that protection. Here's specifically how we secure those keys and what our threat model is."

That's less sexy. It's harder to market. But it's true.

The Security Vs. Convenience Tradeoff

Password managers are in an impossible position, and they know it.

Users demand features. They demand account recovery so they don't get permanently locked out. They demand vault sharing so they can manage passwords with family and colleagues. They demand group management so organizations can maintain shared credentials.

But every one of these features creates cryptographic complications that reduce zero-knowledge guarantees.

Here's what the tradeoff looks like:

Maximum Security (True Zero-Knowledge):

No account recovery
No vault sharing
No group management
Master password forgotten = data is unrecoverable
Single-user vaults only
Much harder to use

Maximum Convenience (Current Implementation):

Account recovery enabled
Vault sharing between users
Group management for organizations
Recovery if you forget your master password
Easy family and team collaboration
Reduced cryptographic guarantees

Password managers chose convenience. And maybe that was the right choice—most users would rather have convenient password management with reduced security than inconvenient password management with perfect security.

But the tradeoff should have been explicit. It should have been in the terms of service. It should have been in security whitepapers. Instead, we got bold marketing claims about zero-knowledge, which are technically true but misleading without the full context.

What You Should Actually Be Doing Right Now

Let's be practical. What should you do with this information?

First, understand that having a password manager is still infinitely better than not having one. Even with these vulnerabilities, a password manager with encryption is far more secure than password reuse. The risk from a password manager hack is lower than the risk from credential compromise through phishing or social engineering.

Second, if you use Bitwarden, Dashlane, or LastPass, evaluate whether you actually need account recovery. If you have your master password stored securely—written down in a safe, stored in a safety deposit box, memorized and rehearsed—you probably don't need it. Disable it. It's one less attack surface.

Third, if you have vault sharing enabled, understand that shared items have weaker protection than non-shared items. Shared passwords are valuable targets. Keep them to a minimum. Only share passwords that absolutely need to be shared. And think about whether you really need the convenience of password manager sharing, or whether password rotation plus out-of-band communication would actually be better security.

Fourth, keep your password manager client updated. One of the vulnerabilities involved legacy version support. Running the latest version doesn't eliminate the vulnerability, but it reduces it.

Fifth, have a conversation with your password manager company. Ask them: How exactly do you protect recovery keys? What integrity checks do you use? Can I disable features to increase security? Most companies either can't answer these questions precisely or will reveal that you have very limited controls.

Sixth, use two-factor authentication on your password manager master account. If someone does compromise the vault, at least they can't change your master password and lock you out.

Seventh, understand that no password manager is perfect. They're all making architectural tradeoffs. The best one for you is the one whose tradeoffs align with your actual threat model and use case.

The Path Forward: What Password Managers Need to Do

The researchers didn't just identify problems. They suggested solutions. Here's what needs to happen:

1. Authenticated Encryption Everywhere

Every piece of data transmitted from server to client needs to be authenticated with a message authentication code. This prevents public key substitution and other tampering attacks. It's standard cryptographic practice. It's not optional.

2. Transparent Threat Modeling

Password managers need to publish detailed threat models. For each feature, specify exactly what an attacker with server access can and cannot do. Be specific. Stop saying "zero-knowledge" as a blanket claim. Start saying "zero-knowledge except for X, Y, and Z, which we protect with [specific mechanism]." This is technical honesty.

3. Key Rotation with Integrity

When implementing key rotation, ensure that every step involves integrity checks. The public key must be signed and verified. The recovery ciphertext must be authenticated. Keys must be rotated atomically—either fully rotated or not at all. No intermediate states where data is vulnerable.

4. Recovery Without Compromise

Develop account recovery mechanisms that don't require server-side access to encryption keys. Some options: user-controlled recovery keys that are encrypted with the recovery phrase, distributed recovery through trusted contacts, or integration with secure enclave technology. There are cryptographically sound alternatives.

5. Vault Sharing Redesign

For shared vaults, use cryptographic techniques like proxy re-encryption that allow sharing without giving the server access to plaintext. It's mathematically possible. It requires more computational work, but it's doable.

6. Regular Third-Party Audits

The researchers found that multiple professional audits hadn't caught these vulnerabilities. This suggests audits were too focused on known attack patterns and not enough on cryptographic assumptions. Password managers need to fund audits specifically designed to question architectural assumptions, not just find implementation bugs.

7. Bug Bounty Programs with Substantial Payouts

The fact that these vulnerabilities existed for years despite academic research suggests they weren't being looked for. Substantial bug bounties for cryptographic vulnerabilities could change incentives. If researchers know they can earn significant money for finding authentication bypasses or key distribution flaws, more will look.

The Bigger Picture: Why This Matters Beyond Password Managers

The password manager vulnerability story is important not just for password manager users, but for the broader conversation about security claims in modern software.

We live in an era of security theater. Companies make bold claims about their security architecture—zero-knowledge, end-to-end encryption, military-grade security—without explaining what those claims actually mean or what their limitations are.

Password managers are actually one of the better actors in this space. They do implement real encryption. They do use legitimate cryptographic techniques. The vulnerabilities researchers found aren't the result of negligence—they're the result of fundamental tension between security and usability.

But that tension should be transparent. Users should know what they're getting. Instead, they get marketing copy about zero-knowledge and military-grade encryption, which create false confidence.

This research is a reminder that security claims need to be specific, audited, and—most importantly—publicly explained. When a company says their system is "secure," you should demand specificity: secure against what threat, under what assumptions, with what tradeoffs?

For password managers specifically, the answer is increasingly clear: they're reasonably secure against server compromise as long as you don't use convenience features. Once you enable those features, the protection degrades. That's not necessarily a reason to avoid password managers—the convenience is worth the risk for most people—but it's a reason to make that decision with eyes open.

What to Look for in Your Next Password Manager

If you're evaluating password managers, here's what to actually look for rather than trusting broad security claims:

1. Clear Documentation

Find a password manager that publishes detailed security architecture documentation. Not marketing whitepapers. Actual technical documentation explaining how encryption works, what assumptions are made, and what happens when those assumptions are violated.

2. Limited Attack Surface

Prefer password managers that minimize features requiring server-side key handling. Simpler features mean fewer cryptographic complexities. It's unsexy, but it's safer.

3. Transparency About Limitations

The best password manager companies are honest about what they can't do. They say "We can't implement true zero-knowledge account recovery because [mathematical reason]. Instead, we do [alternative approach]." That honesty is reassuring.

4. Regular Audits with Public Results

Password managers should undergo third-party security audits regularly, and the results should be public. Not just "we had an audit," but actual detailed reports about what was tested and what was found.

5. Fast Security Updates

When vulnerabilities are reported, how fast does the password manager push updates? If they're slow to patch cryptographic issues, that's a red flag about their security culture.

6. Cryptographic Expertise

Does the company employ people who actually understand cryptography? Not just programmers who use crypto libraries, but people who have studied and published research on cryptographic security. This matters more than you'd think.

The Realistic Security Model for Password Managers

Here's what you're actually getting when you use a password manager, without marketing language:

A password manager is much more secure than password reuse, which is the only realistic alternative for most people. If your choice is between remembering 50 passwords (which leads to weak passwords and reuse) and using a password manager with known architectural limitations, the password manager wins.

A password manager protects against most realistic threats: phishing, credential stuffing, brute force attacks, credential harvesting. Most hacks happen because users reuse passwords across services, not because password managers are insecure.

A password manager provides reduced protection against a specific, less likely threat: a dedicated attacker who has compromised the password manager's infrastructure at scale. Even then, the protection is significantly reduced, but not zero, if account recovery and sharing features are disabled.

A password manager does not protect against threats like malware on your computer, keyloggers, or someone with physical access to your device while you're logged in. Those are limitations of any system that requires software to function.

Understood this way, password managers make sense for almost everyone. They're not perfect. No system is. But they're dramatically better than the alternative.

Looking Ahead: The Evolution of Password Manager Security

Password managers will evolve. The research pressure is now visible. Companies will move toward better cryptographic practices. The ones that move fastest will gain a competitive advantage.

What we'll likely see:

Better Cryptography: Moving from home-grown encryption schemes toward standardized, well-understood cryptographic approaches. This takes time, but it's already happening.

Simplified Features: Password managers might start offering tiers. A secure tier with minimal features and strong zero-knowledge guarantees. A convenience tier with more features and more honest security claims.

Decentralized Recovery: Using blockchain or distributed trust models for account recovery instead of centralized server-side recovery.

Hardware Integration: Moving sensitive operations to secure enclaves, where even server compromises can't extract certain keys.

Better Transparency: Publishing real threat models, acknowledging limitations, and educating users about tradeoffs rather than making sweeping claims.

The fact that this research came out shows that the security ecosystem is working. Researchers found real problems. They publicized them. Companies will feel pressure to fix them. Users can make informed decisions.

It's not perfect security theater. But it's not pure theater either.