Skip to content

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.

By THEYDIDNTASK
Password Security: A Practical Account Protection Plan
Password Security: A Practical Account Protection Plan

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