Password managers and two-factor authentication, practically

Install a password manager, let it generate a different random password for every account, and stop typing passwords from memory. Then put a second factor on the accounts that can reset all the others (email, domain registrar, bank, mobile carrier), preferring a security key or passkey, falling back to an authenticator app, and accepting SMS only where nothing else is offered.

Reuse is the one failure you can fix alone

Verizon's 2026 Data Breach Investigations Report, the 19th edition, examined more than 31,000 security incidents across 145 countries, including at least 22,000 confirmed breaches, between October 2024 and November 2025. Its headline finding rearranges the usual advice: exploitation of vulnerabilities is now the leading initial access vector at 31 percent, while credential abuse, formerly first place, has fallen to 13 percent. Both figures rest on a sample of 19,905 breaches, errors and privilege misuse excluded.

Thirteen percent of a number that large is not noise, and it is the only vector you can close yourself. Patching someone else's web server is not your job. Making sure your forum password from 2011 does not also open your email is. The human element, which the report defines to include social engineering, phishing and stolen credentials, still appears in 62 percent of breaches, up from 60 percent a year earlier.

Have I Been Pwned listed 17,764,052,966 breached accounts from 1,020 sites when checked on 27 July 2026, and both counters only climb. Its Pwned Passwords service exists for the reuse problem: your manager sends the first five characters of a candidate password's SHA-1 hash, the API returns every hash suffix under that prefix, and the comparison finishes locally, so the password never leaves your machine. NIST SP 800-63B-4 puts the same duty on the site, requiring verifiers to check a new password against a blocklist of known commonly used, expected or compromised passwords, whole string, not substrings.

What the current standard actually says

NIST SP 800-63B-4 was published in July 2025 and supersedes the edition last updated on 2 March 2020. Most password advice online still describes the older document, which matters because several rules inverted.

A password used as a single factor must now be at least 15 characters. One used only inside multi-factor authentication may be as short as 8, and verifiers should permit a maximum of at least 64. Composition rules such as "one uppercase, one digit, one symbol" are forbidden outright. So is forced periodic rotation, with a change required only where there is evidence of compromise. Storing a hint an unauthenticated visitor could reach is forbidden, as is prompting people to answer security questions when they pick a password.

The same section is unusually direct about tooling. Verifiers SHALL allow password managers and autofill, SHOULD permit pasting into the field, and the text records that managers "have been shown to increase the likelihood that subscribers will choose stronger passwords, particularly if the password managers include password generators." That is a federal standard endorsing the tool, not vendor copy. Fifteen characters per site, never repeated, is where memorization stops working.

A manager also concentrates risk, and the same document says so. Its threat table lists Duplication as a class, with two examples that should shape your setup: passwords stored in an electronic file being copied, and "a vulnerability in an insufficiently secure password manager is exploited." So the vault password needs to be a long passphrase used nowhere else, and the vault account needs its own second factor. That step is the one people skip, and without it every unique password inside inherits one point of failure.

Ranking the second factors

Phishing resistance has a narrow technical meaning here. NIST recognizes two routes to it, channel binding and verifier name binding, and names WebAuthn as its example of the second, because the authenticator picks its secret from the authenticated domain name of the site asking. A lookalike domain gets nothing back. Anything that makes you read a code and type it in is excluded by rule, since manual entry "does not bind the authenticator output to the specific session being authenticated." That puts TOTP apps, hardware OTP tokens and texted codes below security keys.

TOTP is still worth having. RFC 6238, published May 2011, took the counter out of RFC 4226's HOTP from December 2005 and replaced it with a value derived from time on a default 30 second step. Both are Informational rather than standards track. It works offline. Its weakness is the live proxy page that collects your code and replays it inside the window.

Push ranks lower than its convenience suggests. NIST names authentication fatigue as a threat, where an attacker fires request after request until you approve one to stop the buzzing, and rules that the older pattern of comparing secrets and tapping approve "is no longer considered acceptable." It requires instead that a secret actually travel between the two channels. Microsoft implements the browser-to-app direction across MFA, self-service password reset and combined registration, and its documentation, last updated 13 February 2026, answers "Can users opt out of number matching?" with a flat no. One caveat most write-ups drop: inside a Microsoft mobile app on the same phone that runs Authenticator, you get a yes or no prompt instead of a number.

SMS is the only authenticator type the whole standard marks as restricted: "At the time of publication of these guidelines, there is one restricted authenticator: the use of the PSTN for out-of-band authentication." Accepting it obliges the credential service provider to offer an unrestricted alternative, warn subscribers about the risk, and write a migration plan for the day it stops being acceptable. NIST's threat table names both failure modes: an operator talked into redirecting the victim's number, and a malicious app reading the code out of the message. Turn SMS on where it is the only option. Turn it off the day the site adds a real second factor, because a weak factor left enabled is a route an attacker can push the login down.

Passkeys, and the distinction most articles skip

A passkey is a FIDO credential built on FIDO2: the W3C WebAuthn browser API plus the FIDO Alliance's CTAP protocol. Neither half is as finished as the marketing implies. WebAuthn Level 3 was still a Candidate Recommendation Snapshot, dated 26 May 2026, when checked in late July 2026.

"Passkey" does not mean "hardware-bound," and this is where marketing and standard part company. NIST separates syncable authenticators, whose private key is exportable through a cloud sync fabric, from non-exportable ones, and the rule is blunt: "syncable authenticators SHALL NOT be used at AAL3." Appendix B, a normative appendix on sync fabrics and cloning, even tells verifiers which WebAuthn Level 3 flags to read. Backup Eligible means the key can be synced. Backup State means it has been. Those are different questions. A synced passkey is a sensible default for ordinary accounts because it survives a lost phone, but it makes your Apple or Google account the thing that governs everything below it. For the account that can reset the rest, buy hardware.

Buy the cheaper key unless you need the extras. Yubico's Security Key Series supports FIDO2/WebAuthn and U2F only, is sold explicitly as a hardware bound passkey device, and lists at 34.51 EUR including VAT on the German store. The YubiKey 5 Series starts at 69.02 EUR and adds OATH-TOTP, OATH-HOTP, PIV smart card and OpenPGP, which matter only if you use smart card login or PGP. Buy two of whichever you pick and enroll both. One key is a single point of failure wearing a security badge.

Losing the second factor

Plan for this before it happens, because the standard is deliberately unhelpful to anyone trying to talk their way back in. NIST recognizes four classes of recovery: saved recovery codes, issued recovery codes, recovery contacts, and repeated identity proofing.

Saved recovery codes are the block of strings a site shows at enrollment, though the standard describes a single code, not the familiar set of ten. Each carries at least 64 bits from an approved random bit generator, the service stores them hashed, and using one invalidates it and triggers a replacement. Issued codes, sent on demand to an address you registered earlier, carry validity windows that show how far each channel is trusted: 21 days to a postal address inside the contiguous United States, 30 days outside it, 24 hours to email, and 10 minutes by text or voice. The SMS window is 144 times shorter than the email one.

How many you need scales with the account. Recovering one that tops out at AAL1 takes a single code. AAL2 requires two codes obtained by different methods, or one code plus a single-factor authenticator already bound to the account, or repeated identity proofing. An AAL3 account proofed in person at IAL3 requires a biometric comparison against the sample taken in that original attended session. "Call support" is not the fallback this document imagines.

So: enroll two authenticators on every account that matters, keep the spare key somewhere other than your laptop bag, and store the printed recovery codes outside the vault they would restore. Every recovery event must fire a notification, to one of at least two addresses the service has to hold for you. That alert is your early warning that someone else is trying. Reporting a lost authenticator is deliberately cheap, since only one factor is required to make the report, so the hour a key goes missing, use that path and kill it.