Passkeys are just passwords that require a password manager

What passkeys actually are

• Many commenters stress that passkeys are asymmetric keypairs, not “random passwords”: the private key never leaves the user’s device, unlike passwords.
• This means a server breach doesn’t leak the credential itself, though it raises questions about how to reset or rotate keys.
• Some push back on the article’s suggestion that passkeys can be “just secret passwords”; others say, from a non‑expert’s perspective, they feel like opaque passwords managed by software.

Password managers, hardware keys, and usability

• Disagreement on “you have to use a password manager”: passkeys can live in hardware tokens (YubiKeys, TPM, Secure Enclave) or in synced software managers (Apple, Google, 1Password, Bitwarden, KeePassXC).
• Hardware tokens are seen by some as even more hassle (you need multiples and backups, can’t always plug them in).
• Non‑technical users’ needs are highlighted: shifting from reused passwords to managers was hard enough; requiring hardware or opaque sync systems is seen as a big additional cognitive burden.

Backup, loss, and recovery risks

• A recurring fear: losing a phone, key, or getting a backpack stolen or house burned down and being locked out of everything.
• Some say the realistic answer is layered recovery: backup email, TOTP, phone prompts, printed backup codes, multiple keys on critical accounts (especially email).
• Others argue many services limit multiple passkeys or don’t expose good recovery flows, making passkeys “the easiest way to lose access to your account.”

Portability, export, and lock‑in

• A central criticism: most mainstream passkey managers don’t let users see or easily export private keys, effectively locking them in.
• Some tools (Bitwarden, KeePassXC) already export passkeys to JSON or plaintext; import between vendors is still immature.
• FIDO “credential exchange” specs are in draft; several commenters are skeptical they will truly prioritize user control rather than reinforcing vendor ecosystems.
• There is heated debate over attestation: the ability for sites to accept or reject specific passkey providers. Some see threats to open‑source managers and worry about eventual blacklisting.

Security benefits and anti‑phishing

• Strong support for the core security model: origin‑bound keys, browser‑enforced domain checks, and the impossibility of “reading a passkey over the phone” greatly reduce phishing and credential stuffing.
• Advocates argue passkeys are designed around the reality that users are the weakest link and routinely fall for social engineering, reuse passwords, and mishandle 2FA.
• Critics counter that the phishing benefits mainly matter for “average users,” while power users lose flexibility and self‑custody.

Centralization, big‑tech power, and “DRM for passwords”

• Many worry about de facto centralization of login through Apple/Google and a handful of managers, plus the risk of account bans or support paywalls.
• Some frame passkeys as “DRM for passwords”: a system that technically prevents users from extracting their own keys, justified by protecting them from themselves.
• Others argue the ecosystem is open in principle and you can choose non‑big‑tech managers or hardware tokens, but opponents see attestation and platform control as long‑term threats.

Maturity and UX concerns

• Several see passkeys as “alpha software shipped too early”: confusing UI, inconsistent browser/platform behavior, unclear migration story, and poor non‑technical documentation.
• Practically, many still keep passwords + TOTP as backup, undermining the simplicity story and making passkeys feel like extra complexity rather than a clean replacement.

Assessment of the article itself

• A number of commenters say the article contains factual errors about the spec (e.g., implying passkeys must be passwords or that copying is forbidden by design rather than implementation).
• Others find its main sentiment reasonable: for people already using strong passwords and managers, passkeys add anti‑phishing but introduce new risks around lock‑in and recovery.