Dashlane’s Vault Theft Shows the Ceiling of Master-Password Managers

On June 2, 2026, Dashlane disclosed that attackers had run a sustained brute‑force campaign against its login flow, successfully registered new devices on a small number of personal accounts, and walked away with the encrypted vaults attached to those accounts. TechCrunch puts the scope at fewer than 20 users — tiny in headcount, enormous in blast radius for each one.

Encrypted vaults are safe right now. They are not necessarily safe forever.

This is the second time in three years a major cloud password manager has had to make that distinction in public. After LastPass in 2022, the industry promised lessons learned. Dashlane actually handled this incident comparatively well: auto‑lockout kicked in, disclosure was fast, scope was small, and the data was encrypted at rest.

None of that changes the fact that a copy of those vaults is now on someone else’s disk, and the only thing standing between the attacker and every password those people ever saved is one human‑chosen master password.

That is the story worth telling. Not “Dashlane bad” — Dashlane did many things right. The story is: the master‑password model is the ceiling, and every cloud vault built on top of it inherits the same ceiling.

What actually happened

Stitching together Dashlane’s advisory and TechCrunch’s reporting, the incident looks like this:

• Attackers did not break Dashlane’s encryption.
• Attackers did not get a classic “we got root on the servers” breach.
• Attackers brute‑forced the 2FA device‑registration flow, guessing six‑digit codes at scale until enough succeeded to enroll a new “trusted” device on a handful of accounts.
• Once a device was trusted, the attacker could pull down the encrypted vault attached to that account.
• Dashlane’s systems eventually detected the pattern, locked the affected accounts, forced password resets, and reset 2FA.

The subtle but crucial point: 2FA was the target, not the wall. The attacker did not need to log in as you in the normal way. They just needed to convince the server to hand them an encrypted copy of your vault.

If you can brute‑force a six‑digit code at scale, against millions of accounts, on a flow that is not aggressively rate‑limited, you will eventually win for somebody.

For those somebodies, the attack now moves offline — onto a private GPU rig, with all the time in the world.

Encrypted ≠ safe forever

Once a vault file leaves the server, the clock starts on an offline cracking job. The attacker no longer has to talk to Dashlane, get rate‑limited, trip alerts, or worry about lockouts. They can throw consumer GPUs, rented cloud GPUs, or purpose‑built ASICs at the file for months. Years, if the vault is interesting enough.

The only things protecting that vault now are:

1. The strength of the master password the user chose.
2. The work factor of the key‑derivation function (KDF) the password manager configured.

That’s it. Two numbers.

Those two numbers are doing battle with the economics of modern offline cracking, which keeps getting cheaper every year. The 2022 LastPass vaults are still being chipped away at in 2026. Some of them have already opened.

Most users’ master passwords are not as strong as they think. Even “good” human‑chosen passwords often land around 30–50 bits of effective entropy once you account for patterns, substitutions, and how people actually generate “random” strings.

If an attacker can test enough guesses per second — and if the KDF parameters are tuned more for login latency than for offline resistance — that is not a comforting margin.

Why Pwdly does not have this ceiling

Pwdly was designed specifically to refuse this trade‑off. Three structural choices matter here, and they compound.

1. No master password — a machine‑generated three‑word phrase instead

When you create a Pwdly account, we generate a three‑word phrase from a curated wordlist of ~7,776 words (an EFF‑style large list). You do not pick the words. You cannot “make it easier to remember” by using your dog’s name. There is no Summer2024! shortcut.

Some back‑of‑the‑envelope math:

• A typical user‑chosen master password — even a “good” one — often lands between 30 and 50 bits of effective entropy in practice.
• A machine‑generated three‑word phrase from a 7,776‑word list has: log2(7776^3) ≈ 38.7 bits of entropy.

The key difference is that 38.7 bits is a floor, not a ceiling. There are no shortcuts, no password123, no “I’ll just append a 1 so I remember it.” Every account gets the full strength of the random draw.

Because we generate the phrase, we also avoid human bias entirely. You don’t get to accidentally pick something that looks strong but collapses under a real cracking dictionary.

2. Argon2id turns each guess into a wall, not a doorway

Pwdly derives your encryption key from your three‑word phrase with Argon2id (RFC 9106), tuned to high memory and time costs.

Argon2id is memory‑hard by design: every guess an attacker makes costs not just CPU cycles but a large chunk of RAM per attempt. That is the lever that breaks GPU and ASIC economics, because the attacker can no longer run millions of guesses in parallel on a single card.

The practical effect:

• A curated three‑word phrase + strong Argon2id parameters is materially harder to crack offline than a typical user‑chosen master password run through PBKDF2 at the iteration counts many password managers shipped before 2023.
• It is also stronger than many post‑2023 configurations that still have to balance mobile performance, legacy hardware, and user‑experience constraints.

And because we control phrase generation, we know the minimum entropy we are feeding into Argon2id. With user‑chosen passwords, vendors are guessing and hoping.

3. The phrase is never saved. Anywhere.

This is the zero‑knowledge half.

Your three‑word phrase exists in exactly two places:

• In your head.
• Briefly, in RAM on the device you are using right now.

It is never transmitted to Pwdly’s servers, never written to disk by us, never recoverable by support, and never present in any database we could lose.

If a Dashlane‑style attacker walked off with our entire database tomorrow, they would get:

• Encrypted blobs.
• Our schema.
• Our row counts.

They would not get a single phrase to reuse or pivot with. They would have to attack each vault’s KDF independently, with no shortcuts and no shared cache.

We have been explicit about this in our own threat‑model write‑ups: the encrypted blob is supposed to be the last line of defence, not the only one. For many cloud vaults, it ends up being both.

Sources

• https://support.dashlane.com/hc/en-us/articles/36038764990866-Security-advisory-Brute-force-attack-on-Dashlane-user-accounts
• https://techcrunch.com/2026/06/02/password-manager-dashlane-says-hackers-stole-some-customers-password-vaults/
• https://www.theregister.com/security/2026/06/01/password-manager-dashlane-suspends-customer-accounts-amid-brute-force-attacks/5248991