Knock Blog

Why Use a Vault — How Password Managers Actually Work

10 min read36 viewsInfra
Bitwarden1passwordValut

The Hassle of Managing Accounts, Tokens, and 2FA

Between work and everyday life, we create — and stay logged into — a staggering number of accounts. Game accounts, a Coupang account, a GitHub account, some shopping site we signed up for once and forgot about. For one reason or another, the accounts keep piling up.

On top of that, if you're a developer, you also end up managing internal system accounts, database credentials, API keys, and more. Since it's practically impossible to set and remember a different password for every account, most people end up reusing one password everywhere — and because of that, when one account gets breached, the rest fall like dominoes. This attack technique is called Credential Stuffing.

A Safe for Your Identity: the Vault

One way to solve these problems is to use a Vault. The best-known services are 1Password and Bitwarden.

For the purposes of this article, a Vault is a store that keeps credentials or sensitive information (e.g., credit card numbers) in encrypted form, and decrypts and serves them only to authenticated parties. The closest dictionary meaning of "vault" is the heavy-duty safe you'd find in a bank.

The Building Blocks of a Vault

Look back at that definition: the information you store is encrypted, and you have to decrypt it to use it. The core of a Vault comes down to exactly those two things — encryption and decryption.

[ Master Password ] ──(KDF)──> [ Master Key ]
                                     │
                                     ├─> Encrypts/decrypts the vault
                                     │
                             [ Encrypted Vault ]
                                     │
                           ┌─────────┴─────────┐
                      Local storage       Server sync
                                       (ciphertext only)
  • Master Password: The one password the user actually remembers. The starting point for everything.
  • Vault: The encrypted blob of data that holds your items.
  • Item: Login credentials, secure notes, cards, ID documents, TOTP seeds, SSH keys, and so on.
  • Sync: The mechanism that lets you use the same vault across multiple devices. The key point is that what goes to the server is always ciphertext.

Isn't Putting Everything in One Place Riskier?

Hearing all this, you might wonder whether concentrating everything in one place is actually more dangerous. Vaults address this problem with key derivation (KDF).

Key Derivation

The master password is never used directly as an encryption key. It goes through a KDF (Key Derivation Function).

master_key = KDF(master_password, salt=email, iterations=N)
  • PBKDF2-SHA256: The long-standing standard. It raises the cost through iteration count. Bitwarden's default is 600,000 iterations.
  • Argon2id: The currently recommended option. It demands not just iterations but memory, making it far more resistant to parallel GPU/ASIC attacks. Available as an option in Bitwarden.

The purpose of a KDF is simple: when an attacker tries to brute-force the master password, make every single attempt expensive. It turns what could have been 10 billion guesses per second into a few thousand per second.

Security Isn't About Making Attacks Impossible — It's About Making Them Not Worth It

There's something worth pausing on here. A KDF does not stop an attack. It only slows it down.

This is really true of security as a whole. No system is unbreakable. The practical goal of security isn't defense — it's imposing cost. The moment the time and compute an attacker has to spend exceeds the value of what they'd gain, the attack simply doesn't happen. A bank vault works the same way. Cut at it with a torch for a few days and it will open. But by then, the police have arrived.

The advice to make your master password long follows the same logic. An 8-character password falls in days, but a four-word passphrase takes centuries on today's hardware. It's safe not because cracking it is impossible, but because by the time it's cracked, it no longer matters.

Keep this lens on as you read the rest, and you'll notice that every mechanism below is telling the same story.

What Zero-Knowledge Means

The server never sees any of the following:

  • Your master password (never transmitted in plaintext)
  • Your master key (exists only on the client)
  • Your vault contents (the server receives and stores only ciphertext)

All encryption and decryption happens on the client (browser extension, app). The server's role is to hold on to an opaque blob it can't make sense of and relay it for sync.

That's why "trusting the service provider" is not a precondition of this architecture. Even if a Bitwarden or 1Password employee deliberately opened up the database, all they'd find is ciphertext.

1Password's Secret Key

1Password adds one more layer on top. When you create an account, it issues a 128-bit Secret Key, and key derivation uses it together with your master password (2SKD, Two-Secret Key Derivation).

The Secret Key is never sent to the server and is stored only on your devices. As a result:

  • Even if the server's data leaks in its entirety, the vault can't be opened without the Secret Key.
  • Even a weak master password becomes practically impossible to brute-force.
  • The trade-off: you need the Secret Key when enrolling a new device → convenience vs. security.

Bitwarden skips this layer and relies on master password + KDF. In exchange, it offers trust along a different axis: open-source auditability and self-hosting.

When the Server Actually Gets Breached — The LastPass Incident

The 2022 LastPass breach showed exactly how far this architecture protects you — and where it stops.

  • Attackers exfiltrated complete encrypted vault backups.
  • The vault contents were still ciphertext → Zero-Knowledge held up.
  • However, some metadata, such as URLs, was stored unencrypted → which services users had accounts with was exposed.
  • And older accounts configured with low KDF iteration counts became targets for offline brute-forcing.

The lessons are clear.

  1. The strength of your master password is the last line of defense. No architecture saves you if your master password is password123.
  2. Metadata must be inside the encryption boundary too.
  3. Keep your KDF settings at current recommended values.

A Vault is not an invincible safe. It's a safe whose cost-to-crack has been raised to unrealistic levels. And a large share of that cost is determined by the master password the user chooses.

So What Do You Actually Get From a Vault?

1) Unique, long passwords "for free."

Since you don't have to remember them, a 40-character random string costs you nothing. The credential stuffing attack path simply ceases to exist.

(Screenshot: different passwords stored per site, being auto-filled)

You can set a different password for every site like this and have them fill in automatically.

2) Phishing resistance — surprisingly the most underrated feature

A Vault's autofill works by matching domains. A naver.com entry will not auto-fill on a lookalike domain like naver-login.co. Human eyes get fooled; the Vault doesn't. The moment autofill fails to trigger is itself a warning sign.

3) A home for things besides passwords

2FA backup codes, API tokens, license keys, passport numbers, Wi-Fi passwords. All the things you never knew where to keep finally get a designated place.

4) Safe sharing

The habit of sending team account passwords over Slack DMs goes away, replaced by shared vaults or one-time links with expiration dates. From an organizational standpoint, the bigger win is being able to revoke access when someone leaves.

5) Auditing and alerts

It automatically finds weak passwords, reused passwords, and passwords that appear in breach databases. (1Password's Watchtower, Bitwarden's Vault Health Reports)

Wait — Is It Okay to Put 2FA Codes in the Vault Too?

Most Vaults can generate TOTP codes (the 6-digit authentication codes). Which raises an obvious objection: if your password and your 2FA live in the same place, is it still 2FA?

Strictly speaking, no. If both factors are in the same safe, the moment the safe opens, both come out. It breaks the original point of 2FA — keeping distinct factors separate.

But you have to look at which threats you're actually defending against. Even with TOTP in the Vault, phishing and credential stuffing are still blocked — a leaked password alone can't get anyone in. What it doesn't defend against is "the vault itself being breached," and at that point everything is already over anyway.

A realistic compromise looks like this:

  • Ordinary accounts: Putting TOTP in the Vault is fine. The convenience gain is significant, and it's far better than not enabling 2FA at all.
  • Top-tier accounts (your primary email, banking, cloud consoles, the Vault account itself): Keep these on a separate app or a hardware key. If these fall, your recovery paths disappear with them.

Trade-offs If You Adopt One

I've used both 1Password and Bitwarden. Here are the pros and cons as I personally experienced them.

1Password

Pros

  • Because the Secret Key is part of key derivation itself, the vault can't be opened even if your master password is stolen or the server's data leaks wholesale.
  • Quite polished UX, a Chrome extension, and native apps too! → It automatically fills in the credentials you've saved in the Vault on the matching websites.
  • SSO integration is available.

Cons

  • Wicked pricing.
  • You now have to keep the Secret Key stored somewhere too, so you end up constantly worrying about losing it. I kept my Emergency Kit in a personal cloud drive. That's not ideal, though — if the cloud account gets breached, one of your defense layers disappears. Printing it on paper and storing it physically is the textbook approach, and if you do keep it in the cloud, I recommend at least locking that account down with a hardware key.

Bitwarden

Pros

  • Affordable. Even the free tier supports unlimited items and unlimited device sync, which makes it genuinely practical.
  • Most of what 1Password offers is here too.
  • Chrome extension and app support.
  • It's open source, so you can audit the code yourself — and self-host if you want.

Cons

  • Unintuitive UX. Autofill often fails on complex login forms.
  • The master password is effectively your single line of defense. Bitwarden does support 2FA. But that protects the login step, which doesn't help if the encrypted vault is exfiltrated wholesale from the server. From that point on, the attacker can make unlimited attempts offline, and the only defenses left are your master password's strength and your KDF settings. 1Password's Secret Key, as we saw, is baked into key derivation itself, which renders that offline attack meaningless. They operate at different layers. → If you use Bitwarden, make your master password long, and I strongly recommend switching the KDF to Argon2id. It takes a few seconds in settings.

So, Which One Should You Use?

On security alone, both are more than sufficient. Both have AES-256, a Zero-Knowledge architecture, and external audits, and if you make your master password long enough, the practical difference is small.

In practice, the decision usually comes down to one question: can I control the strength of the master password? For an individual, you just make a good one yourself, so Bitwarden is plenty. If you're rolling it out to an organization, that becomes a variable you can't control, and 1Password's Secret Key earns its price.

Either way, both are overwhelmingly better than using nothing. There is no worse option than that one password you're currently reusing across ten sites.

If you're starting, here's the order:

  1. Pick a Vault and install it. If you can't decide, start with Bitwarden's free tier.
  2. Create a strong master password. Length over complexity — I recommend a 4–6 word passphrase.
  3. Enable 2FA on the Vault account itself.
  4. Import the passwords saved in your browser, then turn off the browser's password saving.
  5. Rotate passwords in order of importance: email → banking → cloud/dev accounts → everything else.
  6. Run the audit report and check for reused or breached passwords.
  7. Store your recovery codes offline.

Comments

Loading comments...