1. You create or import a credential
The client creates an item containing a password, username, URL, notes, passkey, TOTP seed, attachment, or other supported fields.
Password manager explainer
A password manager is not simply a locked spreadsheet in the cloud. Good designs separate authentication from encryption, derive keys locally, synchronize ciphertext, and decrypt only for authorized clients.
The explanation below describes common patterns and named examples—not one universal architecture shared by every product.
Quick answer
A password manager turns account secrets into key material, encrypts supported vault fields before cloud sync, and unlocks locally. The important differences are salts, KDF settings, metadata, local key storage, autofill, sharing, recovery, software updates, exports, and what the provider still knows.
The client creates an item containing a password, username, URL, notes, passkey, TOTP seed, attachment, or other supported fields.
A salt and password-based key-derivation function add per-account uniqueness and computational work, or the design combines the password with another high-entropy secret.
In an end-to-end encrypted design, the client encrypts protected fields before upload. Exact metadata treatment varies by product.
The service stores and distributes encrypted state plus the account and synchronization data needed to operate the service.
After authentication, the client reconstructs or releases protected key material and decrypts the vault on the device.
A browser extension or operating-system service compares the current domain or app identity with saved item metadata and fills according to configured rules.
Well-designed sharing can encrypt an item or vault key for another authorized account instead of sending plaintext through the provider.
Recovery determines who can restore access. Exports create a separate copy that may be encrypted, plaintext, or tied to the original product.
A server can decide that an account may receive encrypted data without possessing the keys needed to read it. Providers use different terminology and key hierarchies, so the table describes functions rather than one product's internals.
| Layer | Job | What the server may hold | Failure example |
|---|---|---|---|
| Authentication | Proves an account or device may sign in | Verifier, account state, MFA, device and security events | Credential stuffing, stolen session, bad recovery |
| Key derivation | Turns human secrets into cryptographic material | Salt and parameters; not normally the secret itself | Weak password enables offline guessing |
| Encryption | Makes protected vault fields unreadable without keys | Ciphertext and field/object structure | Stolen encrypted vault becomes an offline target |
| Synchronization | Delivers encrypted changes between clients | Ciphertext, versions, object sizes, timing, account metadata | Rollback, deletion, conflict, or availability failure |
| Local unlock | Releases or reconstructs keys on an approved device | Normally no plaintext server copy | Malware or an unlocked stolen device reads data |
| Autofill | Matches saved items to a website or app | Domain/app matching and feature state | Phishing, clickjacking, iframe, or malicious-page abuse |
| Sharing | Lets another authorized identity decrypt selected data | Membership, wrapped keys, authorization state | Excess permissions, retained copies, bad offboarding |
| Recovery | Restores authentication or access to key material | Recovery relationships and account state | Recovery abuse or permanent lockout |
| Export | Creates a portable vault copy | Nothing if local-only; provider may log the event | Plaintext file leaks through disk, backup, or cloud sync |
We used current security white papers, platform documentation, standards, CERT material, and academic research. We did not inspect code, capture telemetry, benchmark KDFs, test extensions, reproduce sharing or recovery, self-host a service, or simulate a breach or malicious update.
A salt is public random data that makes identical passwords derive different results and reduces the value of precomputed attacks. A password-based key-derivation function then consumes computation and, for memory-hard designs, memory for every guess.
Bitwarden documents PBKDF2 and Argon2id options. 1Password combines the account password with a device-generated Secret Key. These are examples, not universal requirements. Work factors can change as hardware improves, and older accounts may need a deliberate parameter or key upgrade.
In an end-to-end encrypted design, supported vault fields are encrypted before upload. The service stores ciphertext and sends it to authorized clients. It still operates account authentication, availability, synchronization, software delivery, and often retains operational metadata.
Apps may keep protected local key material so a user can unlock with Face ID, Touch ID, Windows Hello, Android biometrics, or a device credential. Apple and Android document the general platform pattern: successful authentication authorizes Keychain/Keystore access or a cryptographic operation. The fingerprint or face template is not normally the vault encryption key.
Fallback credentials, timeouts, invalidation, secure hardware, and app implementation differ. Malware or physical access to an unlocked device remains a separate risk.
Authorized clients upload encrypted changes and download ciphertext. Previously synced data may remain cached so the vault works offline. That means a lost device can contain an encrypted local vault and protected key material, making device encryption, lock settings, app timeout, and remote device controls important.
Extensions match entries to domains and place user-interface elements inside or above a hostile web environment. Exact-domain matching can reduce phishing risk, but USENIX and CERT research shows risks involving automatic fill, iframes, malicious scripts, extension UI spoofing, and DOM-level clickjacking.
Those studies apply to tested products, versions, and threat models; they do not prove every current extension is vulnerable. Mobile autofill uses OS frameworks and has its own confused-deputy risks documented in USENIX Security 2022.
Sharing can encrypt an item or vault key for another user's public key or an organization/family hierarchy. Bitwarden organizations and 1Password shared vaults are documented examples. Server authorization can still enforce roles and membership.
Revoking access controls future authorized use. It cannot guarantee deletion of a screenshot, export, copied secret, or credential already used by a recipient.
“Recovery” can restore different things through different authorities. A product can preserve a zero-knowledge vault model while enabling authorized key rewrapping or trusted recovery—but the details determine who can help whom.
Restores the right to sign in, but may not by itself recreate encryption keys.
Lets an existing device or trusted process approve a new client.
Restores access to decryption material through a documented key hierarchy.
A trusted person gains view or takeover rights after approval or a waiting period.
An organizer helps a household member under the provider's family design.
An administrator restores a managed member who enrolled in the recovery system.
Uses an Emergency Kit, recovery code, key file, or protected backup outside the provider.
MFA makes unauthorized online sign-in harder. It usually does not add entropy to an encrypted vault an attacker already possesses because offline guessing depends on the encryption design and account secrets, not a later server challenge. Verify any architecture that claims to bind another factor into key protection.
A manager can store a passkey private key as encrypted vault data and present it only for the matching relying party. The website stores the public credential. Passkey sync, sharing, Credential Exchange, export, and recovery are still evolving, so a passkey inherits the vault's provider, device, and recovery model.
Exports can be plaintext, encrypted, or vendor-bound. CSV and common JSON formats are broadly compatible because they are readable—which is also why they are dangerous. Test the destination import, keep the file out of synced folders, and remove every copy you can identify.
Deleting one export does not prove erasure from SSD history, backups, temporary files, endpoint tools, or cloud synchronization. Deleting a vault or account can also leave legal, billing, security, backup, or recipient records under current policies.
Local-only vaults avoid a hosted sync provider but shift backup, multi-device access, conflict handling, and disaster recovery to the user. Self-hosting changes who operates the server while adding TLS, patching, logs, access control, backups, monitoring, and availability work. Neither is automatically safer.
| Failure mode | What can happen | Practical mitigation |
|---|---|---|
| Weak master password | A stolen encrypted vault may be attacked offline using its salt and KDF parameters. | Use a unique, strong account password and current KDF settings. |
| Provider breach | Account records, sessions, metadata, source code, or ciphertext may be exposed depending on the incident. | Evaluate the exact data and rotate affected secrets when required. |
| Compromised device | Malware may capture keystrokes, memory, clipboard contents, screenshots, or filled values after unlock. | Patch devices, use device encryption, and remove untrusted software. |
| Phishing or extension spoofing | A malicious page may imitate extension UI or manipulate fill behavior. | Use official extensions, verify domains, update promptly, and prefer deliberate fill where appropriate. |
| Malicious update | A client that can legitimately decrypt the vault could be modified to copy data after unlock. | Trust signed distribution, update channels, build security, and incident response. |
| Recovery abuse | A weak recovery channel or overpowered administrator may restore access. | Review who can recover whom, waiting periods, alerts, and offline codes. |
| Sharing and offboarding | Recipients may retain exports, screenshots, or prior copies after access is revoked. | Share the minimum, rotate credentials, and treat revocation as future-access control. |
| Plaintext export | A migration file can expose the whole vault through local storage, backup, or cloud sync. | Prefer encrypted export when compatible and clean up every copy. |
| Lost local-only vault | Device failure or a forgotten password can make a local database unrecoverable. | Maintain tested, protected backups and a recovery plan. |
| Self-hosting failure | Missed updates, TLS errors, exposed admin access, or bad backups can defeat the intended benefit. | Self-host only with ongoing operational capability. |
A breach can expose account records, sessions, source code, development systems, metadata, encrypted vaults, or plaintext. These are not equivalent. Stolen encrypted vaults are serious because attackers can perform offline guesses against weak account passwords using the captured salt, KDF parameters, and ciphertext.
Vault encryption protects stored data. Malware with sufficient access after unlock may capture keystrokes, clipboard contents, filled values, screenshots, browser data, memory, or exports. Password managers do not replace device encryption, updates, endpoint security, or phishing awareness.
A client that legitimately decrypts a vault could be modified to copy data after unlock. This makes code signing, update channels, build systems, extension stores, source review, and incident response part of the trust model. This is an architecture boundary, not an allegation that any provider delivered a malicious update.
Compare those differences in Best Password Managers for Privacy. For the broader safety verdict, read Are Password Managers Safe?.
It stores credentials in an encrypted vault, derives keys from account secrets, synchronizes encrypted data when cloud sync is used, decrypts locally on authorized devices, and fills matching sites or apps.
Documented zero-knowledge systems generally do not store or transmit the master password in recoverable form. Authentication and key-derivation designs differ, so verify the exact provider.
A salt is public random data added to password-based derivation so identical passwords do not produce identical results and precomputed attacks are less useful. It does not need to be secret.
A password-based KDF performs deliberately expensive computation to turn a human password into key material and make each offline guess costlier.
It is a KDF parameter controlling computation, memory, or both. Recommended settings can rise as hardware improves, and old accounts may need a deliberate upgrade.
In documented end-to-end encrypted managers, supported vault fields are encrypted by the client before cloud storage. Exact field and metadata scope varies.
A genuine zero-knowledge architecture is designed so the provider lacks the required vault keys. Recovery, organization administration, shared vaults, and client software still affect the model.
Authentication proves an account or device may sign in. Encryption determines whether ciphertext can be read. A server can authenticate access without possessing plaintext vault keys.
The server can store and deliver ciphertext. Authorized clients download encrypted state and decrypt it locally after unlock.
Face, fingerprint, or device credentials normally authorize access to locally protected key material or a cryptographic operation. The biometric is not normally the vault encryption key.
The extension or OS autofill service compares the current domain or app identity with saved item metadata and applies its fill rules.
Exact-domain matching can help because a credential should not be offered to a lookalike domain. Extensions and autofill still face spoofing, clickjacking, iframe, redirect, and malicious-page risks.
A common design encrypts an item or vault key for another authorized user's public key or an organization key hierarchy rather than sending plaintext through the service.
No. Revocation can stop future authorized access but cannot reliably erase screenshots, exports, prior copies, or credentials already used by the recipient.
Recovery may restore authentication, approve a device, use an offline code, let a trusted contact in, or rewrap keys through a family or organization authority. These are different models.
MFA usually protects online authentication. It does not automatically add entropy to ciphertext an attacker already stole unless the architecture explicitly binds it into key protection.
A manager can store passkey private keys as encrypted vault data and sync them to authorized clients. Portability, sharing, and recovery still vary.
Previously synchronized vault data can often be decrypted locally after unlock. New changes wait to synchronize, and the device may hold an encrypted cached vault.
Some managers offer encrypted exports, while CSV and common JSON exports are plaintext. Check compatibility and remove plaintext copies from local disks, backups, and sync folders.
It avoids some provider-side exposure but increases backup, device-loss, conflict, update, and recovery responsibilities. It is a different tradeoff, not an automatic upgrade.
Self-hosting changes the server operator. The operator must maintain updates, TLS, access control, logs, backups, monitoring, and disaster recovery.
The impact depends on whether attackers obtained account data, sessions, metadata, source code, development systems, encrypted vaults, or plaintext. These incidents are not equivalent.
Malware with sufficient access may capture filled values, clipboard data, keystrokes, memory, screenshots, or plaintext exports. Vault encryption does not replace device security.
In principle, a modified client that legitimately decrypts the vault could copy data after unlock. This is why signed distribution, update security, code review, and incident response matter.
Depending on the service: account email, billing, support, device and login events, diagnostics, website analytics, alias routing, sharing membership, and synchronization timing or size metadata.
Yes. Apps can store, generate, copy, and sometimes fill through operating-system integrations. Extensions make website saving and filling more convenient but add attack surface.
Check encrypted fields, KDF settings, MFA, local unlock, recovery, sharing, audits, extension behavior, export formats, platform support, telemetry, deletion, and incident response.
Current architecture references were checked on July 12, 2026. Provider sources are examples of documented implementations; academic and CERT sources apply to tested systems, versions, and threat models.
The useful core is simple: derive keys locally, encrypt supported vault fields, synchronize ciphertext, and decrypt only for authorized clients. The real differences live in KDF parameters, metadata, local key storage, autofill, sharing, recovery, software delivery, exports, and device security.
Use the Password Manager Decision Hub when you are ready to choose, or compare built-in and dedicated options in Password Manager vs Browser Passwords.
Join for beginner-friendly software guides and get a practical checklist to help compare tools before you pay for another subscription.
No spam. Unsubscribe anytime.