Why we built a password manager without a vault

Most password managers start from the same assumption: you have secrets, so you need somewhere safe to put them. Build a vault, encrypt it well, sync it everywhere, and guard the keys.

MoolKey starts from the opposite question. What if there were no secrets to put anywhere?

The vault is the liability

An encrypted vault is a remarkable piece of engineering. It is also, by definition, a single concentrated copy of everything that matters to you, sitting on a server, waiting. The encryption is usually excellent. The problem is structural: the value is all in one place, and that place has an address.

When a vault provider is breached, the headlines are always some version of the same sentence, “the data was encrypted, so users should be safe.” That is true right up until someone’s master password turns out to be weak, or a future attack makes today’s parameters look quaint. The encrypted blob does not expire. An attacker can take their time.

We did not want to spend the next decade defending a blob.

Recompute, don’t retrieve

MoolKey is deterministic and stateless. Instead of looking a password up, it derives it on demand from a few inputs:

• the site or app you are signing in to,
• a masked identifier (usually your email),
• a per-account version number,
• and your master key, which never leaves your device.

Run those through 600,000 rounds of PBKDF2-SHA256 and you get a strong, unique password. Run the exact same inputs tomorrow, on a different supported device, offline, and you get the byte-for-byte identical result. MoolKey stores the account metadata, not the generated credential.

github.com + masked email + v1 + master key
        │
        ▼  PBKDF2-SHA256 · 600,000 iterations
        │
        ▼
   Kq7$mZ2pX9vL

The password exists in the active browser flow while you are using it. MoolKey does not persist the generated credential in its account storage.

What a breach looks like now

This is the part we care about most. Imagine our database leaks tomorrow. What does the attacker actually get?

• A bcrypt hash of your login password.
• Masked identifiers like mil…ry@gmail.com.
• Canonical app names (google, github).
• A handful of integers and timestamps.

Those records are not a vault of generated credentials. The backend does not contain a saved password list to crack.

The trade we made on purpose

Honesty matters more than marketing here, so we will say it plainly: this model has costs.

There is no account recovery. If you forget your master key, we cannot email it to you, because we never had it. And MoolKey deliberately avoids reading or autofilling your pages, so signing in is a copy-and-paste rather than a one-click affair.

We think those are the right trades. A system that can recover your Master Key is a system where someone other than you can reach it. We would rather avoid storing a generated credential list and ask you to remember one good key.

Who this is for

If you want the most convenient autofill experience on earth, a great vaulted manager will serve you well, and we will happily point you to one. If the idea of a permanent encrypted copy of your life on someone else’s server has always nagged at you, MoolKey was built for that nagging feeling.

One Master Key in your head. Generated credentials are recomputed instead of stored.