Beyond the password · 6 min read
How password managers work
A vendor-neutral look inside password managers: the encrypted vault, the master password, autofill by domain, sync, and what can still go wrong.
A password manager is a small encrypted database of your logins, plus software that fills them in for you. That is the whole idea. Everything interesting is in the details: how the database is locked, how the right password reaches the right website, and what happens if something in that chain fails.
This guide describes the common design without naming products. Managers built into browsers and operating systems, standalone apps and open-source tools all vary, so treat this as the shape of the thing rather than a description of any one of them.
The vault and the master password
The stored logins live in a file usually called the vault. On disk and on any sync server, the vault is encrypted. The key that decrypts it is not stored anywhere in usable form. Instead it is derived from your master password each time you unlock the manager.
Derivation uses a deliberately slow key-derivation function, the same family of algorithms that websites use to store password hashes: PBKDF2, scrypt, Argon2 and similar (see how password hashing works). The function takes the master password, a random salt and a cost setting, and produces a key. A wrong master password produces a different key, the decryption fails, and the vault stays closed.
Two consequences follow:
- The master password is the one secret that matters. Anyone with a copy of the encrypted vault can try master passwords offline, as fast as their hardware and the cost setting allow. No website is in the loop to rate-limit them.
- In many designs nobody can reset it for you. If the provider never sees the master password or the derived key (often called end-to-end or zero-knowledge encryption), the provider cannot decrypt your vault either. Forgetting the master password then means losing the vault, unless you set up a recovery method in advance.
Worked example: what the master password has to withstand
Suppose an attacker obtains an encrypted vault and the manager’s key derivation is slow enough that they can test 10,000 master passwords per second. That is the site’s “slow hash” illustration, an assumption rather than a measurement. Average time to find the master password is half the search space divided by the rate:
| Master password | Bits | Average time at 10,000 guesses/s |
|---|---|---|
| 8 random lowercase letters | 37.60 | about 121 days |
| 4 random EFF words | 51.70 | about 5,800 years |
| 5 random EFF words | 64.62 | about 45 million years |
The arithmetic for five words: 7,776^5 is about 2.8 × 10^19 possibilities; half of that divided by 10,000 per second is about 1.4 × 10^15 seconds, or roughly 45 million years. A slower key-derivation setting stretches every row further; a faster one shrinks them. Either way, the master password should be chosen at random and be long. Choosing a master password goes into the options.
| Scenario | Rate (assumed) | Situation |
|---|---|---|
| Online, rate-limited | 100 guesses per hour | a login form that slows down or locks out repeated failures |
| Offline, slow hash | 10,000 guesses per second | a stolen database hashed with a deliberately slow, salted scheme (bcrypt class) |
| Offline, fast hash | 100 billion guesses per second | a stolen database hashed with a fast unsalted hash (MD5, SHA-1 or NTLM class) on a high-end GPU rig |
Autofill and phishing
Autofill is more than a convenience. When you saved a login, the manager recorded the web address it belongs to. Later, it offers that login only on a page whose domain matches the saved one.
That matters because a phishing page relies on looking right to a person. It does not have to look right to software. A page at examp1e.com (with the digit one) or example.com.account-check.net can copy every pixel of the real login page, but its domain is not example.com, so the manager offers nothing. The missing autofill prompt is a signal that something is off, and it arrives without anyone having to read the address bar carefully.
The protection has limits worth knowing:
- Matching rules differ. Some managers match the exact host, some match the registrable domain and its subdomains. A login saved for one subdomain may or may not appear on another.
- If autofill does not appear and the person copies the password across by hand, the protection is gone. Manual copying is exactly what a phishing page hopes for.
- It protects the password, not a one-time code typed afterwards. See two-factor authentication explained for why typed codes can be relayed.
For a fuller treatment, see phishing and passwords.
What NIST says about them
NIST SP 800-63B-4, the US federal guideline on authentication, is direct on this point: “Verifiers SHALL allow the use of password managers and autofill functionality. Verifiers SHOULD permit claimants to use the ‘paste’ function when entering a password to facilitate password manager use when password autofill APIs are unavailable.”
It also gives the reason: “Password managers have been shown to increase the likelihood that subscribers will choose stronger passwords, particularly if the password managers include password generators.” A login form that blocks paste works against that.
Generators and reuse
Most managers include a password generator. Because the manager remembers the result, the generated password can be long and fully random, such as 20 characters from all 94 printable ASCII characters (about 131 bits). Nobody has to type it from memory.
The bigger effect is on reuse. When every site gets its own random password, a breach at one site exposes one password that works nowhere else. That defeats credential stuffing, where attackers try leaked email-and-password pairs on many other sites. How a generator should pick characters is covered in how password generators work.
Sync
Most people use more than one device, so most managers sync the vault. In the common end-to-end design, the vault is encrypted on your device before it is uploaded, and the sync service stores only ciphertext. A new device downloads the encrypted vault and unlocks it locally with the master password, often together with a device-specific secret or an approval from an existing device.
In that design, a breach of the sync service exposes encrypted vaults, not passwords. The attacker is back to the offline guessing in the table above, which is why the master password’s strength and the key-derivation cost carry so much weight. Designs that do not encrypt end to end ask you to trust the provider’s servers instead; the documentation of a given manager should say which model it uses.
Risks and trade-offs
A password manager concentrates risk in one place. That is a deliberate trade: one strong secret, well protected, instead of dozens of weak or reused ones. The honest list of what can go wrong:
- A weak or reused master password. Everything downstream depends on it.
- Losing access. A forgotten master password, or the only device that holds a key, can lock you out permanently in end-to-end designs. Recovery options vary; recovery codes and backups covers the general mechanisms.
- Malware on an unlocked device. Software running as you while the vault is open can read what you can read. Encryption at rest does not help against that.
- Autofill on a compromised page. If a legitimate site itself is compromised, domain matching will correctly identify it as the real site. Filling only after a click, rather than automatically on page load, narrows that exposure, and some managers can be set to work that way.
- Software flaws. A manager is software and can have bugs. Keeping it updated matters.
None of these makes reuse or memorized short passwords the safer choice. They are reasons to choose the master password with care, to keep a recovery path, and to pair important accounts with a second factor.
Sources
General explanation, not advice for a particular situation. Updated 2026-10-31.