Leaving a phone in an auto is a hardware problem for about a day. It becomes a two-week problem when the authenticator app was on it, and that failure follows a predictable script. Six accounts with two-factor codes generated only on that handset. Backup codes never saved, because the setup page offered them at the exact moment you were in a hurry. And one of those six accounts holding the email address every other recovery flow points back to. Support tickets, identity checks, and occasionally an account that never comes back at all. The opposite failure is just as ordinary and quieter: one password used everywhere, an old forum breach nobody remembers, and a shopping account signed into by a stranger months later. Neither involves a clever attacker. Both are cheap to fix, and fixing them protects more of your life than any VPN subscription will.
the real threat is reuse, not guessing
Nobody sits at a keyboard trying passwords against your account one at a time. What actually happens is duller. A small site with poor security loses its user table. Those email and password pairs get compiled into lists, and software then tries each pair against hundreds of popular services. That is credential stuffing, and it works for one reason only: people reuse passwords. Your password did not need to be weak. It needed to be the same one.
This reframes what a strong password is for. Length still helps against offline password-guessing attempts once a stolen database is being worked on, and modern sites store passwords through slow hashing designed to make that expensive. But uniqueness is the property that protects you from the common case. A different password per site means a breach at one place stays at that place, and a human being cannot do that from memory past about five accounts. That is the entire argument for a manager.
what actually changes when you start using one
The shift is behavioural, not technical. You stop inventing passwords, so you stop needing them to be memorable, so they stop following a pattern anyone can guess from one example. They become long random strings you never read and never need to. Signing in becomes a browser autofill instead of a recall exercise, and the autofill has a useful side effect: it will not offer credentials on a lookalike domain, because the stored entry does not match. That quietly catches a whole class of fake login pages that a human eye skims past.
cloud vault or self-hosted
A hosted manager encrypts your vault on your device before it is uploaded, so the provider stores a blob it cannot open without your master password. Convenient, synced everywhere, and the failure mode is that provider being unavailable or having a bad day with its client software. Self-hosting removes the third party and hands you the operational burden instead.
# A self-hosted vault on the home server, bound to localhost
# and published through a reverse proxy that holds the certificate
docker run -d --name vaultwarden \
-e DOMAIN=https://vault.example.in \
-e SIGNUPS_ALLOWED=false \
-v /srv/vaultwarden:/data \
-p 127.0.0.1:8080:80 \
--restart unless-stopped \
vaultwarden/server:<release-tag>Create your own account first with sign-ups on, then recreate the container with SIGNUPS_ALLOWED=false so nobody who finds the address can register. Replace <release-tag> with a specific release from the project’s releases page, and update deliberately rather than pulling latest.
I would still default to a hosted vault, for one reason: the vault has to be reachable on the worst day you ever have, and that is precisely the day your home server may also be down. If you do self-host, treat the box as seriously as its contents, which means the basics in my Ubuntu server security checklist and backups you have actually restored from.
the master password and the recovery problem
One password now guards everything, so it needs two properties that pull against each other: hard to guess, and impossible for you to forget. Four or five unrelated words beat a short mangled word comfortably. Write it on paper, once, and keep that paper where you keep documents that matter.
Understand what nobody can do for you. A properly built manager cannot reset your master password, because it never had it. That is the design working correctly, and it means forgetting it costs you the vault. So set up whatever emergency access the product offers, export an encrypted backup occasionally, and decide now who could get in if you were in hospital.
# An offline copy of recovery codes, encrypted before it touches any cloud
gpg --symmetric --cipher-algo AES256 recovery-codes.txt
shred -u recovery-codes.txt
# Now put recovery-codes.txt.gpg somewhere that survives your laptop dying.second factors, ranked honestly
Two-factor authentication means proving something you know plus something you have. The factors are not equivalent, and the gap between the weakest and the strongest is wide.
| Factor | Strength | Main weakness |
|---|---|---|
| SMS code | Weakest, still better than nothing | SIM swap, delivery failures, readable on a lock screen |
| Email code | Weak | Only as strong as the email account itself |
| App-based TOTP | Solid, the sensible default | A convincing fake page can ask you for the code |
| Push approval | Solid, easy to misuse | People tap approve out of habit |
| Hardware security key | Strongest | Costs money, needs a spare |
| Passkey | Strongest in practice | Uneven support, recovery differs per platform |
TOTP is the six-digit code that rotates every thirty seconds, computed from a shared secret and the clock. No network needed, which is why it keeps working on a train through Bihar with no signal. Hardware keys and passkeys go further because the secret is bound to the real site’s domain, so a copy of the login page cannot use them at all. For most people the right answer is app-based TOTP on everything that offers it, and a hardware key on email and banking if the budget allows.
the lost-phone drill
Do this once and the two-week lockout described above becomes an afternoon of mild irritation. When you enable TOTP anywhere, save the backup codes immediately, not later. Use an authenticator that can export an encrypted backup, or add each secret to two devices while you have the setup screen open. Keep the encrypted copy off the phone that holds the app.
- Secure the email account first, since every other recovery route ends there.
- Enable TOTP, then print the backup codes or save them in an encrypted file kept off the phone before closing the page.
- Register a second factor as well, so no single device is the only key.
- Test recovery on one low-stakes account, today, while nothing is broken.
the Indian specifics
We live on SMS OTPs here. Banking, UPI, gas booking, income tax, insurance, all of it. That habit has trained everyone to treat a code arriving by text as proof of security, and it also means your phone number is effectively a master key to your financial life. Two practical consequences. Keep that number active even if you stop using it day to day, because a recycled number in someone else’s hands is a genuine problem. And guard the SIM itself: set a PIN on it, and take a port-out request you did not make seriously and immediately.
Where a service gives you a choice beyond SMS, take it. Google, Microsoft, most exchanges and the better Indian services all support authenticator apps now. Banks largely do not, so SMS stays in your life whether you like it or not. That’s starting to change. Reserve Bank of India directions with compliance due by 1 April 2026 let payment providers use factors other than SMS OTP, so use any stronger option your bank offers. Wherever SMS remains, the mitigation is boring vigilance: no code goes to anyone who calls you, ever, regardless of which department they claim to be from. That is the same discipline I argue for in the VPN myths piece, where the tool people trust is rarely the one doing the work.
passkeys, and where this is heading
A passkey replaces the password rather than adding to it. Your device holds a private key, the site holds the matching public key, and signing in is a cryptographic proof plus your fingerprint or device PIN. Nothing reusable is transmitted, so there is nothing for a breach at the site to expose and nothing for a fake page to collect.
The problems that remain are uneven support and messy recovery. Your passkeys live in a platform keychain or your password manager, and the question of what happens when you switch from Android to iPhone has better answers than it did but not clean ones. My approach: enable passkeys where offered, keep the password and TOTP in place as the fallback, and let the accounts that matter most lead the migration. Your browser is part of this story too, which is why I wrote up the settings that actually change your exposure in the browser privacy guide.
common mistakes
- Storing TOTP codes in the same vault as the passwords, then protecting that vault with nothing but the master password. One compromise, both factors.
- Enabling two-factor authentication and skipping the backup codes. This is the single most common way people lock themselves out.
- Leaving the email account on a reused password while hardening everything downstream of it.
- Choosing a master password so complex you cannot recall it under stress, then writing it in a notes app.
- Using security questions honestly. Your mother’s maiden name is not a secret; treat those answers as extra passwords and store them in the vault.
- Approving a push prompt you did not trigger. If a code or approval arrives unexpectedly, someone has your password already and it is time to change it.
FAQ
is the browser’s built-in password manager good enough?
It is far better than reuse, and for someone who will not adopt anything more involved, use it and move on. The limits are that it is tied to one browser ecosystem, it handles non-web credentials poorly, and sharing with family is clumsy. I would rather see a relative using Chrome’s manager consistently than a dedicated app abandoned after a week.
what if the password manager company is breached?
Then an attacker holds an encrypted blob whose key is your master password, which the company never had. A long master password keeps that blob impractical to open. This has happened to real providers, and the accounts that suffered were the ones with short master passwords or weak vault settings, which is a strong argument for a long passphrase rather than for avoiding managers.
do I still need this on public Wi-Fi?
More than ever, though not for the reason people expect. HTTPS already protects your login on a café network, so the network is rarely where credentials go astray. The real risk is a lookalike sign-in page, and a manager that refuses to autofill on the wrong domain is a better defence than any tunnel. I went through what is actually risky on shared networks in the public Wi-Fi guide.
Order matters more than speed here. Email and banking go into the manager first, then app-based TOTP on those two accounts, with the backup codes kept somewhere your phone cannot take with it. Everything else can follow at whatever pace suits you.
Update history: the Vaultwarden example now turns off open sign-ups and pins a release, the NIST reference points to SP 800-63-4, and the backup-code and Indian banking advice has been brought up to date.
Sources
- NIST SP 800-63-4 Digital Identity Guidelines — authenticator strength, why forced rotation and composition rules are prohibited, and length over complexity.
- RFC 6238 — TOTP, the time-based one-time password algorithm every authenticator app implements.
- RFC 9106 — Argon2, the memory-hard function some vaults offer for deriving a key from your master password.