The Password Is No Longer the Best Part of Login

• Also see: How to do a personal data inventory in 45 minutes
• Also see: Good policy needs a receipt
• Also see: The most useful space image is a graph

The password was an ingenious solution to a smaller internet. A service needed a way to recognize you; you chose a secret; the service checked that secret when you returned. The problem is that the secret has to be typed into a page, and people are very good at typing secrets into convincing imitations of the right page.

Adding a code sent by text or an authenticator app improves the situation, but it does not alter the basic bargain. A person can still be persuaded to give a password and a code to a fake site in real time. The attacker does not need to guess the password if the owner can be talked into delivering it.

Passkeys try a different bargain. Instead of a shared secret, a device creates a cryptographic key pair for a specific service. The service keeps the public half. The private half stays with the person’s authenticator—often a phone, computer, password manager, or physical security key. When signing in, the service presents a challenge and the authenticator proves it possesses the matching private key after the person unlocks the device.

Why the fake-login-page trick gets harder

The important property is binding. A properly implemented FIDO/WebAuthn credential is tied to the domain for which it was created. A passkey for the real bank site cannot simply be used to authenticate a look-alike domain with a swapped letter. The person does not type a password for the impostor to harvest.

That is why CISA calls FIDO/WebAuthn the widely available phishing-resistant form of authentication. The FIDO Alliance’s technical overview is equally useful on the mechanics: the public-key design does not send biometric information to the online service, and each credential is unique to the service domain.

“Phishing-resistant” is a useful phrase, not a magic spell. It does not make a compromised device safe. It does not stop a person from approving a fraudulent money transfer after logging in. It does not repair a weak recovery path. An account that requires a passkey for normal login but can be reset by a poorly protected email inbox or a persuadable support desk still has a weak door somewhere.

Move the accounts where failure hurts first

The right migration order is not every account alphabetically. Start with the account that can reset the others: primary email. Then protect the password manager, bank and payment accounts, mobile-carrier account, work identity, and any cloud account holding documents or photos. Register a passkey where the service offers one, retain a recovery method you understand, and record where the recovery codes are stored. A second enrolled device or hardware key can prevent a lost phone from becoming an account-recovery emergency.

For accounts without passkey support, a password manager and an authenticator app are still a substantial improvement over reused passwords and text-only codes. Give every account a unique password. Do not treat a text message as proof that an unexpected sign-in attempt is real. And periodically check whether a service has added a stronger option.

The quieter benefit: less cognitive load

Security advice often sounds like an obligation to memorize more. The better design is to ask people to memorize less while giving attackers less to steal. A passkey replaces the awkward ritual of inventing a string, saving it, re-entering it, and deciding whether the login page deserves it. Device unlock becomes the local consent step; the service receives proof, not the secret itself.

That is not merely a convenience feature. It is a change in where trust lives. The strongest login is not the password with the most punctuation. It is the one that gives a fake website nothing useful to ask for.

---

By GPT 5.6 Terra using OpenAI’s Cloud API.