The article looks like either author knows something I don't (but fails to link any source on their claims), or is a bunch of misinformation.
> Passkeys are randomly generated passwords that are required to be managed by a password manager.
This is not correct. Passkeys are keypairs, and unlike shared secrets (like passwords) they do not require private key material to be ever revealed to the remote system. That's the whole point of Webauthn - so servers never ever possibly see any secret credentials.
Otherwise - yes - they're random-looking blobs of data that is handled by a special software (which can be a password manager, but is not limited to password managers - e.g. an HSM like Yubikey can be used without any password management software), but that's where the similarity ends.
> Passkeys can be public/private keypairs, or they can just be secret passwords.
To best of my awareness, this is incorrect. I'm really curious where this idea comes from. In my understanding of the Webauthn spec it's all about public-key cryptography, attestations always use PublicKeyCredential. I'm not aware about any way to use a static token instead. Maybe it's possible to bastardize the standard somehow, but I doubt it's a real concern.
> Password managers provide no way for you to copy and paste your passkeys.
This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary.
> A passkey manager is morally required to do an extra factor of authentication [...] but the site/app has no way of knowing/proving whether that happened
This is partially correct. There is attestation in Webauthn, but to best of my awareness it's something frowned upon, so IMHO it's best if we all pretend it doesn't exist. If attestation is not required (which is AFAIK how most Webauthn-supporting services operate), it's up to user to decide on how they secure their system. And that's a good thing (YMMV), because it allows end user to have freedom of choice.
> This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary.
This thread is one of the guys from FIDO threatening to blacklist keypass for doing just that, using the spec'd passkey attestation feature as the tool to do so. Just because the attestation feature isn't widely used as a weapon just this second doesn't mean that is not the intended endgame, in fact I'd argue the hand was tipped in that very thread.
> Passkeys are randomly generated passwords that are required to be managed by a password manager.
This is not correct. Passkeys are keypairs, and unlike shared secrets (like passwords) they do not require private key material to be ever revealed to the remote system. That's the whole point of Webauthn - so servers never ever possibly see any secret credentials.
Otherwise - yes - they're random-looking blobs of data that is handled by a special software (which can be a password manager, but is not limited to password managers - e.g. an HSM like Yubikey can be used without any password management software), but that's where the similarity ends.
> Passkeys can be public/private keypairs, or they can just be secret passwords.
To best of my awareness, this is incorrect. I'm really curious where this idea comes from. In my understanding of the Webauthn spec it's all about public-key cryptography, attestations always use PublicKeyCredential. I'm not aware about any way to use a static token instead. Maybe it's possible to bastardize the standard somehow, but I doubt it's a real concern.
> Password managers provide no way for you to copy and paste your passkeys.
This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary.
> A passkey manager is morally required to do an extra factor of authentication [...] but the site/app has no way of knowing/proving whether that happened
This is partially correct. There is attestation in Webauthn, but to best of my awareness it's something frowned upon, so IMHO it's best if we all pretend it doesn't exist. If attestation is not required (which is AFAIK how most Webauthn-supporting services operate), it's up to user to decide on how they secure their system. And that's a good thing (YMMV), because it allows end user to have freedom of choice.