Password Manager Architecture

A modern password manager is really two systems joined together: a local cryptography client that can unlock secrets, and a sync service that stores encrypted blobs without being able to read them.

The flow starts when you create an account and choose a master password. That password should never be sent to the service in plain form. Instead, the client uses a slow key derivation function such as PBKDF2 or Argon2 to turn the master password into a strong encryption key. The slowness is deliberate. It makes offline guessing far more expensive if an attacker steals encrypted vault data. Some products also add a device stored secret or account key, so the server alone does not hold enough material to support large scale password guessing.

Once the client has derived its unlock key, it generates one or more random vault keys. Those vault keys encrypt the actual items: website passwords, secure notes, API keys, recovery codes, and sometimes shared team credentials. The important design choice is key wrapping. The vault key encrypts the data, and the master derived key encrypts the vault key. That lets the software rotate one layer without having to re-encrypt every item from scratch.

When the vault syncs, the server usually receives encrypted records plus metadata such as item type, timestamps, and account identifiers. Good systems minimise exposed metadata, but some metadata has to remain visible so sync, conflict resolution, and sharing can work. This is why password managers are often described as zero knowledge in practical terms rather than magical terms. The provider should not know your passwords, but it still knows that your account exists, when devices connect, and roughly how much encrypted data you store.

Browser extensions and mobile apps add another layer. They need to detect login forms, match them to stored entries, and fill usernames, passwords, or one time codes. That convenience introduces risk. A malicious website can try to trick an autofill engine with hidden fields or deceptive domains. Good managers counter this with strict origin matching, user approval for sensitive fills, and warnings for lookalike domains, but the endpoint still matters. If your laptop is infected with malware or a fake extension, local encryption does not save you once the vault is unlocked.

Sharing inside teams uses separate keys again. A shared vault is normally encrypted with its own random key, then that key is wrapped for each authorised member or group. When someone is removed, the service may need to rotate keys or re-wrap access so the old member cannot keep receiving updates. This is one reason enterprise password management is more complicated than personal storage.

Recovery is another tradeoff. Strong client side encryption means the provider often cannot simply reset your vault if you forget the master password. Some services offer recovery through trusted devices, emergency kits, admin assisted recovery, or organisation managed keys. Every recovery feature improves operability but widens the trust boundary.

So what can still go wrong? Weak master passwords remain a problem. Phishing pages can steal credentials before the password manager ever helps. Sync conflicts can overwrite recent edits if clients reconnect badly. Providers can also make bad implementation choices, such as weak key derivation settings or flawed browser integration. A password manager meaningfully reduces password reuse and storage mistakes, but it does not remove the need for multi-factor authentication, secure devices, and scepticism about where you type your secrets.