As far as I can tell: it's a system of private keys stored on devices, in order to transmit a key you also need to unlock a device (e.g. phone) with some other method like a PIN or fingerprint/face scan. Combine those two things and it means a would-be hacker would need both the physical device as well as the local authentication for that device (PIN or biometrics).
> You can either sync passkeys to an online account and across multiple devices, or use multiple passkeys stored in multiple physical authenticators.
But all of that has to be set up in advance, right? What happens if I really only have a single passkey, associated with my phone, and then lose the phone?
The upcoming W3C Web Authentication Level 3 defines a "backup capable" authenticator, which means that it goes beyond a single piece of hardware. Indicating "backups enabled" means that the user has a recovery process, such as if they store the passkeys in their iPhone and then lose/upgrade the model - they can just sign into iCloud on the new device.
Not all authenticators are going to have backups enabled (even ones which are backup capable), so these are really meant as hints so that a website (a la Relying Party in the spec) can guide the user to a proper experience. For instance, if you use a hardware security key fob, they may recommend you keep your password and SMS enabled as options, so you can get in even if you lose it.
> For instance, if you use a hardware security key fob, they may recommend you keep your password and SMS enabled as options, so you can get in even if you lose it.
But if you have this and the old authentication methods, doesn't that greatly reduce the security gains of this? I mean, the old methods still exist, so what you've done is increase the attack surface.
It can be used on both Android and iOS. Desktop machines can display a QR code which you scan with your device. Passkeys are backed up to the cloud using E2E encryption. If you get locked out of that device, you can do the same thing as when you lose your password.
> do the same thing as when you lose your password.
If this is a Google Service, then that means begging, pleading, threatening, crying like a baby, then finally posting a rant on HN to get the service unlocked.
Google is fairly infamous for making it near impossible to recover lost account access, or appeal bans.
I have an account that I’m never getting back. I made an error, when setting it up, that resulted in me losing the password (I saved the wrong one, in 1Password). It’s been a few years, but I remember trying everything to get it back, and was stymied at every turn.
Eventually, I gave up. The reason I registered the account, was because it was the name of one of my corporations, and I didn’t want fraudsters registering it.
Mission accomplished. Ain’t no one using that account.
In principle it can be synced between any is, it just depends on the cloud/implementation. Eg. 1Password is currently adding Passkey support, that would probably work on any device they have browser plugins and the private key material is stored and synced through 1Password vaults.
As far as I can tell: it's a system of private keys stored on devices, in order to transmit a key you also need to unlock a device (e.g. phone) with some other method like a PIN or fingerprint/face scan. Combine those two things and it means a would-be hacker would need both the physical device as well as the local authentication for that device (PIN or biometrics).