Password Security: A Practical Account Protection Plan
Use unique passwords, passkeys and multifactor authentication with a recovery plan grounded in current NIST and FIDO guidance.

TL;DR
- —Use a password manager to generate a different password for every account that still requires one.
- —Prefer passkeys or hardware-backed security keys when a service offers them, especially for email and the password manager itself.
- —Do not rotate passwords on a schedule; change them when they are exposed, reused, or suspected of compromise.
- —Store recovery codes and an emergency plan somewhere you can still reach after losing a device.
Correction, October 7, 2026: This guide now incorporates an overlapping
password article. We removed unsupported breach totals, entropy and crack-time
estimates, corrected claims about browser password managers and passkey
portability, and updated the source guidance to NIST SP 800-63B-4. Account security is a system. A strong password cannot compensate for a compromised
recovery inbox, a phishing approval, or recovery codes stored only on a lost phone.
The practical goal is to make each account independent, make phishing harder, and
keep a recovery path that an attacker cannot easily use. Protect the accounts that reset everything else Start with the email address that receives password resets. Then secure your
password manager, primary Apple or Google account, financial accounts, cloud
storage, and mobile-carrier account. For each one, record: the sign-in address and recovery email or phone;
which passkeys, security keys, or authenticator apps are registered;
where the recovery codes are stored; and
which old devices or sessions still have access. Do this inventory before a crisis. Recovery is much harder when the only registered
device is missing. Use a different generated password for every remaining password login Password reuse turns one service breach into attempts against unrelated accounts.
A password manager solves the memory problem: remember one strong account password
or passphrase, then let the manager generate and store unrelated passwords for
individual sites. For generated passwords, choose a long random value within the site’s supported
limit. There is no useful universal promise that a certain length will take a stated
number of years to crack. Offline guessing depends on how the service stored the
password, the key-derivation cost, the attacker’s equipment, and whether the choice
came from a predictable pattern. For the manager’s own account password, use a long passphrase that is unique to the
manager. Randomly selected words can be easier to enter and retain than a short
string decorated with predictable substitutions. Do not reuse an example phrase
from an article, book, or meme. Writing an emergency copy on paper and storing it securely can be reasonable. The
risk depends on who can access the location. A categorical rule against every
physical backup can leave a person locked out without meaningfully reducing their
real threat. Apply current password guidance accurately NIST SP 800-63B-4 addresses services
that verify passwords. It sets a 15-character minimum for password-only login and
permits a lower minimum when the password is part of multifactor authentication.
It rejects arbitrary character-type rules, calls for checking proposed passwords
against a blocklist, and says services should allow managers, autofill, and paste. For an individual, the useful rule is to avoid cosmetic scheduled changes. Replace
a credential when it was reused, exposed, shared, entered on a suspected phishing
page, or included in a breach corpus. Add a phishing-resistant sign-in where it is available A passkey uses a cryptographic credential tied to the legitimate site. The service
stores a public key; the passkey provider controls the corresponding private
credential. Because authentication is bound to the site, a lookalike domain cannot
collect a reusable password from the user. “Passkey” does not describe one storage model. A passkey can be synced through a
credential provider or remain bound to a device or hardware security key. FIDO’s
cross-device authentication can let a nearby phone approve sign-in on another
device, but that does not mean every credential automatically transfers between all
providers. Before removing a password fallback, check: which devices or security keys hold the passkey;
whether the provider synchronizes or exports it;
how the service recovers an account after device loss; and
whether another trusted authenticator is registered. For the highest-impact accounts, two hardware security keys stored separately can
provide a durable primary and backup. Confirm that the service supports them before
buying hardware. Use multifactor authentication with clear expectations An authenticator-app code adds a barrier when a password is stolen. It can still be
phished if a person enters the live code into an attacker’s page. SMS can help when
it is the only second factor offered, but it depends on the phone number and carrier
account. Passkeys and FIDO security keys provide stronger phishing resistance when
the service implements them correctly. Save one-time recovery codes outside the password manager if losing access to the
manager would also block those codes. An encrypted offline copy or a paper copy in a
controlled location can serve that purpose. Do not leave recovery codes in an
unlocked photo gallery or ordinary note synchronized to the same account they
recover. Check exposure without creating a new exposure Have I Been Pwned lets people check whether an email address appears in its breach
database. Its Pwned Passwords service uses a k-anonymity design: a client can query
a hash prefix rather than send the full password or complete hash. Do not type a current master password into an unfamiliar website because it claims
to check breaches. Review the checker’s data flow first. Our
Password Strength tool explains what it evaluates and
what, if anything, leaves the browser; a strength estimate is not proof that a
password is secret or safe to reuse. A one-session account plan Secure the recovery email and password-manager account.
Turn on a passkey or strongest supported MFA for those accounts.
Save recovery codes somewhere reachable without the same phone or vault.
Replace reused passwords, starting with financial and cloud accounts.
Remove obsolete recovery addresses, phone numbers, sessions, and devices.
Set breach notifications for the email addresses you use. The result is layered protection: one service leak does not reveal another account’s
password, a phishing page has less reusable material to steal, and a lost device
does not force an unsafe recovery shortcut.
Sources
- NIST SP 800-63B-4: Authentication and Authenticator Management
Current federal guidance for password verifiers, phishing-resistant authenticators, and recovery.
- FIDO Alliance: Passkeys
Passkey concepts, synced and device-bound credentials, and cross-device authentication.
- CISA: Secure Our World
Practical account-security guidance including password managers and multifactor authentication.
- Have I Been Pwned: Pwned Passwords
Password exposure checking with a k-anonymity design that does not send the full password or full hash.