The strongest criticism of deterministic password managers isn’t a tweet. It’s a careful essay by cryptographer Tony Arcieri titled Four Fatal Flaws of Deterministic Password Managers. Years later it’s still the best argument against the model. So instead of dodging it, we’re going to walk through it flaw by flaw.
Two of the classic “fatal flaws” are real trade-offs, and two are solved by design. Deterministic managers genuinely can’t store secrets you didn’t generate, and a weak master key is genuinely catastrophic. But per-site rules and rotation, long treated as dealbreakers, are handled by a thin layer of non-secret metadata and a deliberately slow hash. Here’s the full accounting.
The four flaws, steelmanned
The critique, fairly stated, is that a pure “password = f(site, master)” function: (1) can’t satisfy conflicting site password rules, (2) can’t store secrets you didn’t generate, (3) can’t rotate one password and collapses entirely if the master leaks, and (4) lets an attacker brute-force your master offline if any single derived password is exposed. Each is worth taking seriously.
Flaw 1: “It can’t handle different password rules”
Sites disagree on length limits, required symbols, and banned characters. A pure function can’t know those rules, so either it produces something a site rejects, or you end up storing per-site configuration anyway.
MoolKey’s answer is to embrace the second half honestly: it keeps a small amount of non-secret metadata per account (the canonical app name, a masked identifier, a per-account version integer, and the length and format you chose), which feed the derivation’s parameters. The site rules problem is solved by remembering your settings, not by pretending settings don’t exist.
The argument was never “store absolutely nothing,” it’s “do not store the generated credentials.” MoolKey’s masked identifiers and settings are not passwords, but they still count as account metadata and can reveal which services you use.
Flaw 2: “It can’t store secrets you didn’t generate”
Pre-existing passwords, recovery codes, SSH keys, secure notes: a deterministic manager can’t hold any of them, because it only knows how to recompute, not remember.
This one is true, and we don’t pretend otherwise. MoolKey derives passwords and PINs; it is not a vault for arbitrary secrets. If your priority is stashing backup codes and notes, a vaulted manager is the better tool, and we’ll say so plainly, it’s the same caveat we make in our vaulted vs deterministic comparison. For passwords specifically, you migrate by rotating each account to a freshly derived one, which is its own short no-import switching guide.
Flaw 3: “You can’t rotate one password, and a master leak dooms everything”
The rotation half is solved cleanly: MoolKey gives every account a version integer. Bump a single site from version 1 to version 2, change the password there, and only that password changes. Every other account is untouched, and your master key never changes.
The harder half is true in spirit. If your Master Key is exposed, every derivable password is at risk. But notice the asymmetry against a vault: the Master Key is never stored, never transmitted, and never leaves your device, so there is no server-side copy to exfiltrate, and every guess has to survive 600,000 rounds of PBKDF2. A vaulted master-password compromise is equally catastrophic: it decrypts the entire vault. Neither model survives a compromised master; MoolKey does not keep that key in its backend.
Flaw 4: “One leaked password lets attackers brute-force your master offline”
This is the flaw that actually matters. If a single generated password leaks and an attacker knows it came from a deterministic scheme, they can test master-key guesses offline by re-deriving that known password and checking for a match. Vaulted managers, the argument goes, add encryption-at-rest as a second independent layer.
The defense is twofold and we won’t oversell it:
- Cost per guess. Re-deriving any candidate runs the full 600,000-iteration gauntlet, so an offline search is enormously expensive, the same asymmetry that protects a vault’s master password, per OWASP’s guidance.
- A strong master key. Against a high-entropy passphrase, even an expensive-per-guess search is infeasible. This is exactly why your master key choice is load-bearing in a way it isn’t for a vault that can also rate-limit online attempts.
The honest part: MoolKey can’t add encryption-at-rest as a separate layer, because there’s no blob at rest to encrypt. Our defense in depth is a slow KDF, a strong master, and per-account versioning, not a second copy of your secrets.
So who should avoid it?
- If you need to store arbitrary secrets, notes, or recovery codes, use a vault.
- If you won’t commit to one strong master key you’ll never forget, use a vault, for its recovery and online rate limiting.
- If your real fear is a permanent encrypted copy of your credentials sitting on someone’s server, go deterministic.
In short
- Flaw 1 (password rules): solved with non-secret per-account metadata.
- Flaw 2 (arbitrary secrets): a real limitation, by design.
- Flaw 3 (rotation): solved with a per-account version; a master leak is bad in both models.
- Flaw 4 (offline brute force): mitigated by 600k iterations plus a strong master key.
Frequently asked questions
Are deterministic password managers safe? They can be, when the design accounts for these flaws: non-secret metadata for site rules, per-account versioning for rotation, a slow KDF and a strong master key against offline attacks. A naive “hash the site name” toy is not safe; a parameterized, high-iteration design with a strong master is a different proposition.
What happens if one of my generated passwords leaks? That one account is at risk and should be rotated by bumping its version. The deeper concern is an attacker using the leaked password to brute-force your master offline, which is why MoolKey runs 600,000 PBKDF2 iterations per guess and why a high-entropy master key matters so much.
Can I rotate a single password? Yes. Each account carries a version integer; increment it to get a brand-new password for that site while every other account stays exactly the same.
Is MoolKey just LessPass with a new coat of paint? No. MoolKey shares the deterministic idea but adds 600,000-iteration PBKDF2, per-account version rotation tracked for you, masked identifiers, a dedicated PIN mode, and optional 1-to-1 sharing with a partner. See the LessPass comparison for the specifics.
Want the neutral, non-defensive version of the model first? Read how a deterministic password manager works, then decide for yourself.
Keep reading
The 10 most common 4-digit PINs (and why to avoid them)
The most common 4-digit PIN is 1234. Here are the ten PINs people choose most often, what the public dataset shows, and how to choose a less predictable number.
SecurityAre password managers safe? An honest answer
Password managers are safer than the alternative, but not risk-free. See what breaches teach us and how to judge one.
