Mustafa ERBAY

Posted on Sep 2 Originally published at mustafaerbay.com.tr

Moving Your Family to a Password Manager Without a Fight

#security #learning #uretkenlik

Setting up a password manager at home looks like a technical job. It isn't. Choosing the vault takes half an hour; the real issue is that you are trying to solve a problem nobody else in the house wants solved. Their current system — the note stuck to the fridge, a hundred passwords saved in the browser, the same word with a different digit tacked on the end — works fine for them. Nobody wakes up in the morning wanting to replace something that works.

I look at this as a handover project rather than a security project. The setup is only working if the vault still stands on the days you don't touch your phone.

The Resistance Isn't About Passwords, It's About Habits

The classic mistake technical people make here is treating resistance as a knowledge gap. If that were true, we would show a chart and close the matter. The source of the resistance is usually far more concrete: the person is afraid that tomorrow they won't be able to get into accounts they can get into today. That fear isn't irrational either — nobody can open the vault of someone who forgets their master password, and the provider can't either.

So the person across from you isn't opposed to security, they're opposed to a single point of failure. Starting the conversation there is, to my mind, the shortest path through it. Turn it into a moral argument — "you're still using the same password?" — and the migration dies the moment you leave the room.

The One Argument That Works: It Won't Fill on a Fake Site

Telling your family "your password isn't strong" buys you nothing, because nobody has watched their own password get cracked. There is one behaviour they can see with their own eyes, though: the password manager does not offer to autofill on the wrong domain.

Bitwarden's default match rule looks at the base domain of the saved address; a login saved for google.com is not offered on google.net (URI match detection docs). For someone who has just clicked a link in a phishing email, that isn't a theoretical guarantee — it's a box that either appears on screen or doesn't. The sentence "if it doesn't fill here, this isn't that site" does more work than a long talk about encryption.

Introduce the vault as a mistake preventer, not a security investment.

Start With Five Accounts, and Drop the "Change It Every Three Months" Advice

Trying to move every password on day one kills the migration. Five accounts are enough: email, the bank, the mobile operator, the shopping site they use most, and one streaming service. Email goes first, because it is the recovery address for everything else.

There's also an old piece of advice worth abandoning. Current NIST authentication guidance explicitly says verifiers should not make people change passwords periodically; a forced change is expected only when there is evidence of compromise. The same document forbids imposing character composition rules and sets a minimum of 15 characters for passwords used as a single factor. OWASP's authentication guidance lands in the same place: don't mandate arbitrary password changes, use strong passwords and multi-factor authentication instead.

The practical translation for a household is simple: don't have anyone set a calendar reminder. The long, unique, per-account passwords the manager generates beat adding a digit every three months.

That leaves exactly one password to remember: the vault's own. CISA's password guidance gives a clear target here — long, at least 16 characters, and random; either a mixed string or a passphrase of five to seven unrelated words. For most family members the second option is far more realistic, because it sticks in memory and can be typed on a phone.

One more thing: don't try to do this over text messages. Moving five accounts finishes in a single sitting, at the same table, on the other person's own phone. If you type, the setup is yours; if they type, the vault is theirs.

Choose the Sharing Model: Shared Vault or Copy?

This is an architectural decision, and it is exactly where most home setups quietly break. The first question isn't "which product", it's "when a password changes, does that have to reach everyone".

Sharing in Google Password Manager sends a copy of the password to a member of your family group, and that copy is saved in the recipient's own account. So when you change the password later, their record stays as it was. That's fine for a one-off handover, and wrong for a shared account in daily use.

On the Apple side a Shared Group is a genuine joint space: the person who creates the group is the only administrator — only they can add and remove people, rename the group, or delete it. Items are not copied into the group, they are moved; a password can live in only one group at a time. Everyone's device has to be on iOS 17 or macOS 14 or later.

Two details here matter more, in a family context, than any product pitch. First, everyone in the group can not only edit shared passwords but delete them; you have thirty days to recover a deleted item. Second, and this is the big one: removing someone from the group does not invalidate the passwords they already saw. Apple's own safety guide says so plainly and recommends changing those passwords after you remove someone. The group is not a revocation boundary — and the realistic household scenarios, a child growing up or a housemate moving out, test exactly that.

If the ecosystem is mixed — an Android, an iPhone and a Windows laptop, which is the usual case — a shared vault produces less friction. Bitwarden's Families plan covers six users and shares through collections. I went into the security side of choosing a vault in an earlier piece on the differences between open source and commercial options; the question here is a different one — not "which is safer" but "does a change propagate".

Say Up Front What You Won't Share

A shared vault doesn't mean everything is shared, and saying so at the start ends the argument before it starts. What goes into the shared space should be a short list: home internet, streaming and music subscriptions, the electricity and water utility accounts, joint shopping accounts.

Banking and official identity accounts don't belong on that list. The reason isn't technical: transactions on those accounts belong legally to one person, and a shared login makes it impossible to say who did what. Everyone keeps a private vault, and the shared space sits next to it.

Old passwords saved in the browser deserve a conversation at this stage too. When two sources offer autofill at the same moment it isn't obvious which one is right, and as far as I can tell people eventually stop trusting both. Turning off the browser's own vault once the migration is done is less a technical cleanup than a way to prevent confusion. And if you do the bulk move with an export file, remember what it is: that CSV is plaintext on disk. Delete it the moment the import finishes, and empty the trash too.

Putting one-time code generators in the same vault means a single vault password unlocks both the password and the second factor. For most family members that trade is still worth it, because the alternative is that they never use a second factor at all. Just go in knowing it's a concession.

A Vault Without a Recovery Plan Is a Trap for a Family

This is the most-skipped part of the migration. Nobody can open the vault of a person who has lost their master password; handing your family a vault without a recovery plan is like giving them a room with a door and no key.

I covered Bitwarden's emergency access mechanism — the difference between view and takeover, the wait time, the paid-plan requirement — in detail in the digital legacy piece. There is one item to add in a family context, and most setups miss it: emergency access covers items in your individual vault, in the documentation's own words. Passwords in a shared collection do not transfer this way.

The consequence is direct. If you build a shared collection for the family and remain the organization's only owner, the shared space becomes unreachable the moment you do. Emergency access won't rescue it. The fix isn't a different product, it's naming a second owner on the organization — the five-minute part of the setup that invalidates the whole plan when it's skipped.

Apple's recovery contact is a completely different thing, and the two get confused. That person only gives you a code during account recovery; they get no access to your account, your data or your passwords. You can name up to five, and both sides need iMessage turned on. One is a mechanism for taking over a vault, the other is a witness who helps you unlock your own.

How to Actually Rehearse the Recovery

Writing "an unrehearsed recovery plan is not a plan" and then not saying how to rehearse it would be taking the easy way out. Concretely: drop the wait time to one day, ask your trusted contact to open an access request, then check three things. Did a notification reach you when the request was opened? Did rejecting it actually close the request? And when you let the timer run out, did access open on its own?

That third step is smarter to run against a throwaway account than your real vault, because takeover replaces your current master password and removes your two-step login methods. Put the wait time back to its real value when you're done. Half an hour of work, and the only real test the setup gets.

If You're Going to Self-Host It, Know This

Building your own vault with Vaultwarden is a topic of its own, but moving your family onto it is a different level of responsibility. Emergency access ships enabled by default — the EMERGENCY_ACCESS_ALLOWED setting is true — and the job that approves requests once the wait time expires runs as a scheduled task.

The real trap is in the mail settings, and people usually look for it in the wrong place. Invitations sent to already-registered users are auto-accepted when email is disabled, so the invitation side causes no trouble. Here's what does: the alert that tells you a takeover request was opened also depends on email. With SMTP broken you never hear about the request, the wait time expires quietly, and your right to reject it exists only on paper. The thing to test in a home setup isn't whether the vault opens — it's whether that alert arrives.

The bigger issue is this: you're making your family's ability to log in depend on your server staying up. My own server dropped off the network quietly for about a day at the end of June — no alarm fired, nobody told me. For a blog that's embarrassing; for a morning when someone can't get into their banking app it's something else. Vault clients keep a local copy, so offline reading works in most cases, but setting up a new device and syncing both stop while the server is down. For a home setup my own preference is to host my vault and leave the family's on a hosted service.

A Checklist Before You Call the Migration Done

Five accounts are moved, and autofill has been tried on each device.
What goes in the shared space has been agreed, with banking and official accounts left out.
The shared collection has a second owner and doesn't depend on one person.
Every adult has a defined recovery path: emergency access, a recovery contact, or both.
The recovery path has been rehearsed once, and the notification was seen to arrive.
Old browser-saved passwords are cleared and the export file is deleted.
A paper backup of the vault password is somewhere physically safe in the house.

Security That Can't Be Handed Over Isn't Security

Building a family vault is a maintenance commitment, not an installation task. If a year later nobody remembers their master password, no recovery contact is defined, and every failure lands on your phone, that setup didn't raise anyone's security — it just piled the fragility onto you.

So it's worth changing the measure of success from the start: not how many passwords were moved, but how many people can get into their own accounts without you. Black boxes get through their worst nights without telling anyone; your family's password vault shouldn't be a black box.

DEV Community