Home · Blog · Security

Password managers and unique passwords: the system that actually works

Nobody can memorise a hundred strong, unique passwords — and nobody needs to. This guide explains the one-master-password model, how to migrate from reused passwords without drowning, and the settings (length, 2FA, recovery) that decide whether a manager makes you safer or just differently vulnerable.

The arithmetic of modern accounts defeats unaided memory: the average person juggles dozens to over a hundred logins, and a strong password must be both long and unique to each. Humans resolve that impossibility predictably — by reusing a handful of passwords everywhere — and attackers industrialised the consequence: credential stuffing, in which username/password pairs leaked from one breach are tried automatically against hundreds of other services, succeeds precisely because reuse is the norm.

A password manager breaks the arithmetic by moving the memory burden to software. You memorise one strong master password (ideally a passphrase); the manager generates, stores and fills a different random password for every account. This article covers the model honestly — including its real risks — and the migration path that makes adopting one a weekend project instead of a life sentence.

Key takeaways

  • Unique per account is the property that contains breaches: one site's leak should compromise exactly one login.
  • Generated passwords should be long (16–20+ characters) and random; with a manager filling them, typing cost is zero.
  • The master password is the keys to the kingdom: make it a 5–6 word passphrase, and protect the manager with two-factor authentication.
  • Migration is triage, not perfection: email and banking first, then anything with a payment method, then the long tail.

Why uniqueness matters more than cleverness

Consider what a breach actually gives an attacker: typically a list of emails and password hashes from one service. Against well-hashed storage they recover the weaker passwords by cracking; those recovered pairs are then machine-tested everywhere else within hours. Your clever, fairly strong password — the one you are proud of — fails in this story not because it was guessed, but because it was present. If it guards one account, the damage is one password change. If it guards thirty, the damage is your email, and through password resets, effectively everything.

Uniqueness converts a systemic risk into a series of small, containable ones. It is also the property no human memory strategy can deliver at scale, which is why "use a manager" is not a brand recommendation but a mathematical one.

Setting up the vault properly

  1. Choose a reputable manager — built-in browser and OS managers are vastly better than reuse; dedicated cross-platform managers add sharing, auditing and portability. Whichever you pick, enable its breach and weak-password reports.
  2. Set the master password as a generated passphrase of five to six words (about 65–78 bits), one you will type daily until it is muscle memory. Write it down on paper and keep that paper somewhere physically safe until you are certain it is memorised — a forgotten master password is the one failure mode no support desk can fix.
  3. Turn on two-factor authentication for the manager itself, preferably an authenticator app or hardware key, and record the recovery codes with the paper copy.
  4. Set generator defaults once: 20 characters, all character families, for every new password; passphrases of five words where a human must type (TV logins, Wi-Fi).
  5. Decide the unlock policy: biometric unlock on your own devices is a good trade; a short auto-lock timeout protects shared machines.

The migration, in triage order

Do not attempt to fix a hundred accounts in one sitting — that is how vaults get abandoned. Migrate in rings. Ring one, today: your primary email (it resets everything), your banking and payment accounts, your Apple/Google ID, and the manager itself. For each: log in, change the password to a generated one, store it, add two-factor authentication while you are there. Ring two, this week: shopping, social, cloud storage, work tools — anything with a saved card or private data. Ring three, opportunistically: the long tail, migrated lazily at next natural login, prompted by the manager's "weak/reused" report as your checklist. Ninety days of opportunism finishes what a heroic weekend would not.

Two traps to avoid while migrating. Changing passwords on a machine you do not trust moves the risk rather than removing it — use your own device. And never let the migration stall at "save this password?" dialogs declined out of haste: a changed password not saved to the vault is tomorrow's lockout.

The honest risk ledger

A manager concentrates risk, and pretending otherwise helps no one. If your master password is phished or your unlocked device is taken, the vault is the prize. The mitigations are real, though: a strong unique master passphrase resists guessing, two-factor authentication resists remote attack, an auto-locking vault resists casual access, and reputable managers encrypt the vault with keys derived from your master password so their servers never hold it in readable form. Weighed against the alternative — reuse, which is not a hypothetical risk but a routinely exploited one — the ledger is not close. The residual dangers worth your attention are phishing generally (a manager's refusal to autofill on a lookalike domain is actually a defence here — heed it when filling fails) and endpoint malware, against which the answer is a patched, ordinary-care device.

Mistakes and pitfalls

Storing the vault's master password inside the vault

Circular and common. The master password lives in your memory and on your paper backup, nowhere digital — certainly not in the thing it unlocks.

Keeping one 'good' password for important sites 'because the manager might fail'

A shadow system of memorised exceptions quietly restores reuse at the highest-value accounts. If vault failure worries you, the answer is the paper backup of the master password, not exceptions.

Letting the browser and a dedicated manager both save, inconsistently

Two vaults drifting apart — some logins in each, some stale in both — causes lockouts and bad autofills. Pick one home for passwords and turn saving off in the other.

Common questions

What if the password manager company is breached?

With a properly designed manager, what leaks is encrypted vaults; their safety then rests on your master password's strength — another reason it deserves six words and 2FA. Weak master passwords have been cracked from stolen vaults in real incidents; strong ones have not, at any published scale.

Built-in browser manager or dedicated app?

The built-ins (Chrome, Safari/iCloud Keychain, Firefox) are encrypted, sync well within their ecosystems, and beat reuse by miles. Dedicated managers win on cross-platform life, secure sharing, passkey and document storage, and detailed auditing. Choose by your device mix; switch deliberately once rather than drifting between both.

Should I also store passkeys in the manager?

Yes, where offered — passkeys are phishing-resistant by design and managers make them portable across devices. Keep generating passwords too; the web is in a long transition where most logins still want one.

To wrap up

The password manager is not a product so much as an admission: human memory is the wrong tool for a hundred unique secrets, and software is the right one. One memorised passphrase, generated passwords everywhere else, two-factor on the vault, migration in rings — that system, unglamorous as it is, is what actually stands between a stranger's breach and your whole digital life.

Try it yourself

Start ring one today: the password generator here makes the 20-character replacements, and the passphrase generator makes the master password — both in your browser, both from a proper random source.

Open the Password Generator