> Passkeys, particularly when bound to a physical security key
And _only_ when bound to a physical security key. Unfortunately by tying into the marketing of passkeys, there is going to be a pervasive assumption that ecosystem/on-device passkeys are just as secure.
Overall a good set of points, and I think it highlights the issues with a lot of the lauded 'convenience' factors in the Apple ecosystem.
> Unfortunately by tying into the marketing of passkeys, there is going to be a pervasive assumption that ecosystem/on-device passkeys are just as secure.
Passkeys are an improvement over passwords. Security keys have a place for high security applications like enterprise deployments or the security paranoid. Passkeys stored on security keys can be trivially made worse by allowing users to set bad PINs (like 0000). If you use an iPhone and iCloud Keychain, iOS won’t permit you to store or use Passkeys with such an obvious passcode, but a Yubikey 5 will.
I feel similarly, improvement is better than no improvement. So far the evolution of mainstream auth was just password -> email/sms, the 2FA stuff in between was niche. Most sites just want that to be someone else's job, passkey is a simple and robust way to do that, unlike oauth.
The problem is that passkeys are opaque, non-portable, inaccessible, magic boxes lacking a backup or a portability mechanism.
Passwords can be shared, stored, backed-up. Passkeys are locked away and hidden.
Passkeys are improvements over passwords in that login/password tuple is replaced by a single string.
Everything else, including hardware tokens, is marketing vendor lock-in.
A passkey is not a single string? A passkey is a public private key pair where the private key is never sent to a server and signs things.
Yep. There is still a lock-in issue though, cause passkeys as implemented are hard to transfer across walled gardens. But at least it's not like early TOTP impls which often had no playbook for when you get a new phone even in the same ecosystem.