I am personally not switching to passkeys unless I see a clear description of all possible failure modes. I.e. Google blocks you, you loose your phone, you want to migrate from one provider to another, when passkeys offer more security and when less.
I feel with authentication, it's always those special cases that determine the usefulness and security, but when passkeys are discussed I never have seen a proper discussion a pros and cons and special cases. At least with regular passwords + 1password I kind'a understand what i am protected against and how to restore from disasters.
1. If I can fully physically own some of my authenticators. Aka if Yubikeys or similar hardware tokens are supported, so I don't have to long-term trust any corporation to correctly and securely store my credentials - with Yubikeys the only trust is that hardware is free of vulnerabilities or backdoors.
2. If I'm guaranteed to be not bound to any single specific authenticator. Aka if I'm safe if I lose a Yubikey, assuming that I've prepared ahead of time (also see the next point).
3. If I can enroll an authenticator without having it physically present. Aka if I can sign up with one Yubikey and then tell the website "here is my phone, here's the public key of the Yubikey I keep in a safe, and here's a public key of a keypair I've generated on an airgapped machine, etched onto a titanium plate and buried in a secret stash, accept those for me as my alternative authenticators even though I don't have my private keys present". Aka if I don't have to run around the house (or worse) to just sign up for a website.
4. If I'm guaranteed to be able to use a software authenticator of my own development, shall I want it (despite whatever site owners may think of it). Aka if there are no attestation requirements that force me to use authenticators I don't trust.
If it's "yes" to all four, then I'm in and advertising this to everyone I know about, because this is much better than a password manager. If 1, 2 and 4 are "yes" then I'm probably in with a mix of one HSM and one software authenticator with exportable private keys (so I have a guaranteed way out), but voicing my displeasure wherever I can as the system is inconvenient. If not, then I'm probably sticking with passwords for the time being.
1, 2, and 4) Yes, that's already possible. Look into Solo Keys for open source hardware and firmware. The standard allows for key manufacturer attestation but seems like the way it is going (especially with the proliferation of software authenticators) it likely won't be relevant in practice. You can also enroll many authenticators to the same account (provided the service allows it, which most do).
3) This is pretty hard/impossible, I think. The authenticators don't use the same key-pair for all websites (a la SSH through Yubikey), but rather create a per-service, per-credential key-pair, and encrypt it with the main key-pair. The encrypted credential key-pair is then handed off to the server for storage, and the service sends it back for the authenticator to decrypt and use during a challenge. Clever trick to not depend on local hardware memory and be able to have unlimited per-credential key-pairs, but afaik prevents you from just "adding lists of public keys".
I'm also not mentioning the resident keys aspect of the standard but that won't fix it as they're still service and credential based.
A simple proof of possession (pop), signed ahead of time, solves #3.
The message:
`{"pay":{"alg":"ES256","msg":"I own this key","tmb":"9PcBWntvjAktwfiPp8WxgOyQOwc1h6Lo1UnB_gkWXKk"},"sig":"eXuV0_HYCM-WnS2CbOnGXdce-9M8AzivCw23Hihtp1h69Ix6HwWCA79FR6cs3Nym2bWJoKajtnIY0xcTnuRnNQ"}`
The public key:
`{"alg":"ES256","kid":"Zami Mobile 2","x":"PZpmb3CI_2LTWcxopqjliqohPpmxFmNwKLb52wJgMg-4Xd0hTRKn7OruUMa3LvHmuTA9pHidocLHnEdOcQ04OA","tmb":"9PcBWntvjAktwfiPp8WxgOyQOwc1h6Lo1UnB_gkWXKk"}`
I see passkeys as a convenience, particularly for low value accounts. They feel more like a more universal implementation of a password manager, because that's really what they are.
What I don't like is this push to have passkeys replace everything. I very much like the 2FA with Security Keys of Google Advanced Protection.
Much of the current security shift seems aimed at minimizing MITM and phishing attacks. These were great low-skill attacks that relied mostly on social engineering. As those attack vectors shrink with better 2FA and things like passkeys, people adapt. I'm already seeing it. Now the focus seems to be on session hijacking and other most sophisticated malware. Nastier stuff, really.
I'm with you though. It's becoming harder and harder to figure out what to do and how to manage things. And the biggest risk seems to be the company you are relying on. If your account IS compromised, they are more likely to ban you than help you.
In this case, 1P would be the password manager for your passkeys as well which means even if Google blocks you, you would still have your passkeys to log into your bank, facebook, etc.
Google blocking you doesn't affect passkeys; you must be thinking of things like "Sign in with Google" where you must sign into Google to sign into another website.
The best thing about passkeys that's not available to traditional passwords is that you can have multiple passkeys that are equally valid, unlike the case with passwords where you can have but one single valid password. As someone who uses both Android and iOS frequently, I can set up passkeys on an Android and then an iPhone without needing to trust anyone (not Google, not Apple) to sync them. With that understanding I can address your concerns:
* If one phone is lost, I can use the other passkey to revoke that particular passkey.
* Even if Google blocks me so completely that my Android is remotely bricked by them, the other passkey still works.
* Migrating from one provider to another is trivial: I might be belaboring the point but you do not need the exact key material to be migrated, you only need a new equally valid passkey.
Passkeys strike me as a solution to a problem that security professionals have—not users.
When I log into a site via Passkeys with Safari on macOS, it shows me a QR code that I have to scan with my phone.
This alone is a huge assumption. My dad can’t stand his phone and will not want to use the thing to login to websites.
Then there’s other problems: what happens if the phone is lost, the battery is dead, or the person doesn’t want to get up and get it? Are they denied access?
That doesn’t even get to what happens if the Passkeys are somehow lost, then I bet where back to something that looks like a username and password.
I know there’s other Passkey UX’s, but of all the implementations I’ve seen to date, they all seem to be built by people in tech for other people in tech. Consideration for non-technical users seems to be lacking.
The MacOS situation has been the most confusing. Neither Safari nor Chrome can use passkeys, which makes me think Apple either doesn't allow/support syncing them directly to the MacOS keychain, or the (windows hello-esque) APIs to access them are just not there.
What I’d expect from Apple is the Passkeys are stored in iCloud Keychain. To use it would ask for Touch ID authentication on that same device, then provide the key to the website after a successful auth.
The “go find your phone and take a picture of this QR code” seems like insanity, even if they’re trying to require two devices to authenticate.
Windows exposes APIs for "windows hello" - which is an easy way for apps to authenticate via usb authenticators or windows' built-in authenticator (when available via TPM). I imagine that, on macOS, such an API would allow apps to authenticate using any passkeys in iCloud Keychain directly, of course with an OS-based user presence requirement like entering system password or using touch ID.
You can just create a new passkey on the device from the new provider and register it with whatever service you are using. You can have multiple keys registered for a single service, like one unique key per device.
In this case, you can use a non-google key manager such as this 1password password manager to manage your keys.
Even when using a Google related app, your key is still on your device, it just won't be synced to your google account anymore in the case that google terminates your account.
Our website is already using public key authentication using Coze. https://github.com/Cyphrme/Coze. We've been doing public key authentication for around 2 years now. No passwords needed, just public key auth.
I feel with authentication, it's always those special cases that determine the usefulness and security, but when passkeys are discussed I never have seen a proper discussion a pros and cons and special cases. At least with regular passwords + 1password I kind'a understand what i am protected against and how to restore from disasters.