Security
Proof your browser isn't a vault.
Chrome and Firefox will save your passwords — and then hand them to any program running as you. That's not a bug. It's the design. Here's the proof: once in plain English, once in code.
The plain-English version
Your browser's "password manager" is protected by exactly one lock: your computer login. Once you're signed in to your laptop, the browser can read every saved password instantly — so anything else running on your account can too.
A bad download. A sketchy browser game. One poisoned package in a project you cloned. The moment it runs — while you're logged in, like you always are — it reads every password your browser saved, in the time it takes to open a file. There's no master password to crack, because there's nothing to crack: the browser was built to unlock for you automatically, and the malware just asks nicely as "you."
This isn't theoretical. It's the single most common way ordinary people lose their accounts. The malware even has a boring industry name — "info-stealers" — because it's that routine. Your passwords, your saved cards, your session cookies: copied and gone before you notice.
The fix is simple to state: your passwords should be locked with something the rest of your computer doesn't have — and they shouldn't sit on the machine at all.
The version with receipts
Don't take our word for it. Chromium and Firefox are open source, and the read path is documented, standard, and short. Here's exactly where the passwords are and how they come out.
Chrome (and every Chromium browser)
Chrome stores logins in a SQLite database — Login Data, table logins, column password_value — encrypted with AES-256-GCM. The AES key lives in Local State, "protected" by the OS: DPAPI on Windows, the login Keychain on macOS, gnome-keyring/kwallet (or plaintext) on Linux.
Read it yourself — the code is open. Search Chromium for the constant that tags the wrapped key: kDPAPIKeyPrefix in os_crypt. The key is DPAPI-wrapped, tagged, and stored — then unwrapped with a single call that protects nothing from you:
const char kDPAPIKeyPrefix[] = "DPAPI";
CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
/*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);No second secret, no password, no prompt. CryptUnprotectData hands the key back to any process running in your session — which is exactly the threat model DPAPI documents: if it runs as you, it is you. The attacker's whole job is three lines: read the key from Local State, unwrap it, AES-GCM-decrypt every row in Login Data. Info-stealer malware has done exactly this for years.
"On-device encryption" doesn't save you either
Google's answer is a 6-digit PIN that encrypts your synced vault. In May 2026, researchers at Phishu showed how thin that is. A convincing fake Google sign-in — adversary-in-the-middle phishing — captures the session and that PIN, and the PIN is the master key to every password and passkey in the synced account. With it, an attacker joins their own device to your Google "security domain" and the whole vault syncs straight to them — complete takeover in one step.
The design flaw: Google lets a device join on the 6-digit PIN alone, with no approval from a device you already own.
Firefox
Firefox keeps logins in logins.json and the key in key4.db, decrypted by NSS's "Secret Decoder Ring" — also open source: security/nss/lib/pk11wrap/pk11sdr.c. If you set a Primary Password, the key is sealed with it.
By default, you haven't — so the key is sealed with the empty string, and a stored "password-check" value confirms that empty password decrypts it. Copy two files out of your profile (key4.db + logins.json), point NSS or the open-source firepwd.py at them, and they decrypt. A lock whose key is taped to the door isn't a lock.
Every browser password store has the same shape: the secret lives where you work, unlocked by the session you're already in. Encryption that the rest of your own computer can undo isn't protecting you from the threat that actually empties accounts — code running as you.
Why Clavitor can't be read this way
Clavitor doesn't keep your vault on the machine. There is no Login Data, no key4.db, no key in Local State — nothing on disk for a process running as you to scrape.
The decryption key isn't sealed with your OS login. It's derived from a hardware tap — Touch ID, Face, or a YubiKey — computed in the browser, used for a single request, then discarded. A credential is fetched over a scoped API exactly when you ask for it, and never cached. Malware running as you finds an empty cupboard.
That's the difference between "encrypted on your device" and "not on your device at all."
Stop trusting the browser with your passwords.
The Clavitor extension fills like your browser does — and keeps the vault somewhere your laptop can't read it.