A password manager is the tool that generates, stores, and autofills unique, strong credentials for every service, encrypted under a master key that only you know. It is the direct answer to the problem behind most account compromises: remembering dozens of unique passwords unaided is impractical, so people reuse them, and reuse is exactly what fuels credential stuffing. This guide explains why to use a password manager, how the zero-knowledge model works under the hood, what the LastPass breach taught the industry, and how Bitwarden, 1Password, and KeePass compare for personal and business use in 2026.
Why use a password manager
The argument is not about convenience, it is about reducing attack surface. A manager breaks three patterns attackers exploit every day:
- Reuse. Every service gets a unique, randomly generated password (for example, 20 characters or a multi-word passphrase). A pair leaked in one breach stops opening doors elsewhere, which is the engine behind credential stuffing.
- Weak passwords. The generator produces entropy no human would type by hand, and strength stops depending on memory.
- Domain-bound phishing. The manager's autofill is anchored to the exact domain. If the user lands on
secure-bank.evil.com, the manager does not offer the credential forbank.com, which acts as an early signal that something is off.
In exchange, the manager concentrates the risk in a single point: the vault. That is why it matters so much to understand how that vault is protected and to pick the right tool.
How the zero-knowledge model works
Zero-knowledge means the service provider can never read the contents of your vault, not even under a court order or after a breach of its servers. Encryption and decryption happen on your device, and all that reaches the server is an encrypted blob that is noise without the master key.
Key derivation (KDF)
The master key is not used directly to encrypt. It passes through a key derivation function (KDF) that turns it into the vault encryption key and hardens it against offline brute force. The parameters matter a great deal:
- Bitwarden defaults to PBKDF2-SHA256 with 600,000 iterations (raised from 100,000 in early 2023 to align with the OWASP recommendation) and offers Argon2id as a stronger alternative against specialised hardware.
- 1Password combines the account password with a 128-bit Secret Key through its 2SKD scheme (Two-Secret Key Derivation) over PBKDF2-HMAC-SHA256. That Secret Key, which never travels to the server, makes offline vault cracking infeasible even with a mediocre password.
- KeePass keeps the database locally in KDBX format and, in KDBX 4, supports Argon2d as the key transform, far superior to the old AES-KDF against GPUs.
The vault is encrypted with AES-256 in an authenticated mode (or XChaCha20 in some implementations). The underlying cryptography is the same family of primitives that underpins certificates and digital signatures, explained in what is PKI.
What the server sees
In a correct design, the server only stores the encrypted blob and some operational metadata. The detail LastPass turned into a lesson is which fields stay encrypted and which do not: URLs, account names, or folders in cleartext are free reconnaissance for anyone who exfiltrates a backup.
Lessons from the LastPass breach
The LastPass breach is the mandatory case study because it failed exactly where the zero-knowledge model looks invulnerable. The public sequence was: in August 2022 an attacker accessed the development environment and stole source code. Pivoting on that information, by late 2022 LastPass acknowledged that the actor had accessed cloud storage (backup buckets) and copied a backup of customer vaults.
The concrete takeaways:
- Not everything was encrypted. The sensitive fields (usernames, passwords, secure notes) were, but the URL of each entry was stored in cleartext. That let attackers prioritise high-value targets (crypto exchanges, banking) inside the stolen vaults.
- The iteration count was not uniform. Many older accounts kept PBKDF2 counts well below the modern value (some at 5,000 or even lower), which cheapened the offline cracking of weak master passwords.
- Backup exfiltration breaks the promise that "the server never sees your vault." The server does not read it, but if the encrypted blob walks out the door, the only remaining barrier is the strength of your master password and KDF.
The downstream consequence was tangible: independent researchers linked 2023 and 2024 cryptocurrency thefts to the cracking of exfiltrated LastPass vaults. The practical conclusion: the master password must be a long, unique passphrase, and it is worth favouring providers that also encrypt metadata and use modern KDFs with high parameters.
Bitwarden vs 1Password vs KeePass
There is no universal winner: there is a winner per threat model. Here is the honest summary.
| Criterion | Bitwarden | 1Password | KeePass |
|---|---|---|---|
| Model | SaaS with self-host option | SaaS | Local, KDBX files |
| Open source | Yes (client and server) | No | Yes |
| Extra anti-brute-force factor | Optional Argon2id | Secret Key (2SKD) | Local Argon2d |
| Sync | Own cloud or Vaultwarden | Own cloud | Manual (your cloud, Syncthing) |
| Passkeys | Stores and autofills | Stores and autofills | Via plugins |
| Enterprise (SSO, SCIM) | Yes | Yes | Not native |
Bitwarden
It is the option with the best balance between transparency and cost. Client and server are open source and third-party audited, and it supports self-hosting. Many technical teams deploy Vaultwarden, a lightweight reimplementation of the backend in Rust, with Docker on their own infrastructure:
docker run -d --name vaultwarden \
-v /srv/vaultwarden:/data \
-p 8080:80 vaultwarden/server:latest
Enabling Argon2id in the account encryption settings is the default recommendation to maximise offline resistance.
1Password
Its differentiator is the Secret Key: 128 bits of entropy that live only on your devices and make offline vault cracking infeasible even with a weak account password, the exact flank that sank the old LastPass vaults. It adds enterprise features (Travel Mode, CI/CD secrets integration) at the cost of being closed source and cloud only.
KeePass
It is the option for anyone who wants full control and zero cloud dependency. The data lives in a KDBX file that you sync through whatever channel you choose. The cost is ergonomics: multi-device sync and team sharing fall on you. It is worth remembering CVE-2023-32784, which allowed recovering the master password in cleartext (minus the first character) from a process memory dump, fixed in KeePass 2.54 (June 2023). Keeping the client updated is not optional.
Personal vault vs business vault
The difference is not only scale, it is governance. A business vault adds:
- Centralised provisioning. User onboarding and offboarding via SCIM and directory sync, so that when someone leaves the company they lose access immediately. This fits the stack described in what is IAM.
- SSO and policies. Login through the corporate IdP (Entra ID, Okta, Google Workspace) and mandatory policies for master key length, MFA on unlock, and minimum KDF.
- Shared collections. Team credentials with granular access control, instead of the antipattern of a service password pasted into a chat channel.
- Managed recovery. Account recovery procedures that do not reintroduce a weak back door, a flow that often becomes the attacker's real target.
For personal use a strong vault plus MFA is enough. For a company, the manager becomes an identity component that must be audited like any other.
Integration with MFA and passkeys
A password manager does not replace the second factor: it complements it. The key decisions in 2026:
- Protect the vault unlock with strong MFA, ideally a FIDO2 key or a passkey, not an SMS OTP. See what is MFA for the detail on factors.
- Storing TOTP seeds inside the manager is a legitimate debate. It improves usability, but it puts the first and second factor in the same vault. For high-value accounts, keep the TOTP on a separate device or use a hardware key.
- Managers already store passkeys. Bitwarden and 1Password act as WebAuthn authenticators and sync passkeys across devices. This accelerates the passwordless migration described in passkey vs password and rests on the FIDO2 and WebAuthn standard.
- For privileged access, require phishing-resistant MFA on the manager itself, following the logic in phishing-resistant MFA.
How to choose: checklist
Reduce the decision to five questions:
- Threat model. Do you need full control (KeePass, self-hosted Vaultwarden) or do you prioritise ergonomics and support (1Password, Bitwarden in the cloud)?
- Verifiable zero-knowledge. Does the provider document its architecture, encrypt metadata, and publish third-party audits?
- KDF and parameters. Can you use Argon2id or a Secret Key, and is the iteration count high by default?
- Enterprise. Does it offer SSO, SCIM, policies, and shared collections if you will roll it out across the workforce?
- Recovery. Is the recovery flow robust without opening a weak back door?
With those answers, any of the three options is defensible. What is not defensible in 2026 is using none of them.
Frequently asked questions
Is it safe to keep all passwords in one place?
Yes, as long as the vault is well protected. The concentration risk is real, but it is offset: without a manager, the practical alternative is reusing weak passwords across dozens of services, a much larger surface. With a long, unique master passphrase, strong MFA on unlock, and a modern KDF, the vault is harder to compromise than the scattered accounts it replaces.
What happens if I forget the master password?
In a correct zero-knowledge design, the provider cannot recover it because it never knows it. Losing it usually means losing the vault, unless you have configured an emergency kit (1Password), a recovery contact, or an exported, encrypted backup. Documenting the recovery procedure before you need it is an essential part of the rollout, especially in a company.
Is the browser's built-in manager enough?
It is better than reusing passwords, but it falls short for serious use. Browser-integrated managers usually offer less control over the KDF, weaker team sharing, and their security depends on the browser profile lock. A dedicated manager adds metadata encryption, enterprise policies, passkey support, and self-hosting options.
Should I store passkeys in the password manager?
For the bulk of accounts, yes: it is the most convenient way to adopt passkeys without fragmenting the experience across ecosystems. For the most critical accounts (administration, privileged access), a device-bound passkey on a FIDO2 hardware key is preferable, since it is not exportable and does not depend on the security of the synced vault.
Related resources
- What is credential stuffing: the attack a manager neutralises by removing password reuse.
- Passkey vs password: the cryptographic model the manager is beginning to store and autofill.
- What is MFA: the factors that should protect the vault unlock.
- What is FIDO2 and WebAuthn: the standard the manager's passkeys rest on.
- What is IAM: the identity stack where the business vault fits.
- Phishing-resistant MFA: the second-factor level recommended for privileged access.
Credential management with Secra
At Secra we help deploy and govern password managers as part of an identity strategy: tool selection based on the threat model, hardening of the KDF and the unlock with phishing-resistant MFA, design of enterprise collections and policies, and validation through controlled account-takeover testing inside Red Team projects to check whether the deployment withstands real campaigns. If you want to structure your organisation's credential management, review our managed cybersecurity services or reach us through contact.
About the author
Secra Solutions team
Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.

