What drives me nuts is how little discussion of this I've seen. People don't even seem aware of the implications of it. It's being pushed hard as a boon to security, which it is in some cases, but at a cost that nobody is even considering or talking about.
I know where this is going. In a few years you'll have to pay a monthly fee to log into anything with your Google account, or Google will start logging into your stuff to harvest data to profile you. (Or both? Why not?)
I'm seeing a lot of new stuff pass on login/password or personal FIDO2 token auth entirely, meaning you can't even use stuff without delegating all authority to one of maybe two or three large companies. Even better I'm seeing OIDC-authenticated third party SaaS services managing SSH keys, giving both the service and the OIDC provider carte blanche shell login access.
Once we make this transition it's going to be well nigh impossible to go back. A few large companies are going to have root on the entire universe forever.
If they could just use their fingerprint/faceID to login (after initial registration on the device) they would be super happy.
Rest of us should be happy there will be less exploits where people give up the keys to their kingdom by clicking on a random email.
If you scroll back, they mention you have to protect everyone to be effective, i.e. high value target friends and family.
Why is everyone yelling about the sky falling down when this is the best thing to happen to authentication since ever?
I was speaking very broadly. May have been a bit of a tangent.
All I'm saying is that authentication is literally the keys to the castle, and inviting third party control of authentication has some scary implications in terms of privacy, monopoly control, and security.
It does, but it doesn't have to. You can use any provider you want, or self-host.
They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created. This is a blessing and a curse.
It's a blessing because it eliminates a whole trove of phishing attacks. After all, if no one can get the private key, they can't steal or share it. Well, of course they could steal the actual device, but that's orders of magnitude harder than stealing online credentials (points to https://haveibeenpwned.com/ ). That's a good thing.
It's a curse because the same person logging in from their ipad, android phone, and desktop PC needs to set up WebAuthn three times. For each domain/website (broadly speaking). If they only set it up once and lose the device, well, they are either locked out or need to have another means of account recovery (username/password, calling a customer service rep).
This curse is what passkeys managed by Apple/Google are attempting to solve.
I believe the WebAuthn 3 draft is going to try to address some of this: https://www.w3.org/TR/webauthn-3/ but that's based on what a co-worker said. A quick scan didn't turn up anything.
If you want to know more about WebAuthn, I wrote a lot more here (my company is going to release an implementation Real Soon Now): https://fusionauth.io/learn/expert-advice/authentication/web...
To clarify I am not talking about the issue of syncing the device's private key. I am talking about the artificial problem these walled gardens are creating by having every single domain getting its own randomly generated private key. The only practical way to keep all of these randomly generated keys synced across multiple devices is to use the "cloud".
If instead the per site key was generated using a private key and the domain name, users would only need to transport that one private key to another device and would get syncing for free without the requirement of the "cloud".
That’s part of the design though. That’s what completely eliminates the ability to do phishing-attacks.
If there were a common root to leak, that would just provide a new target for phishing attacks, and effectively risk reducing a persons entire online security down to 1 shared root-key.
While obviously better than having just 1 common shared password, why reintroduce this risk when you don’t have to?
If the actual domain name is used to generate the key that would also completely eliminates the ability to do phishing-attacks. Paypal.com and PaypaI.com would generate two completely different keys.
Why introduce such a risk when there’s no reason to do that?
In both cases your device has a private key that it needs to secure. In my scenario we remove the third party cloud service.
If I delete a credential, the expectation is that registering a new credential is not going to correlate the authenticator (and thus the user).
If I want to have hygiene steps of rotating the cryptographic key a user uses to log in, I won't want registration to create the same key pair each registration.
And for the cloud sync:
The UX can present that web authentication is an option to log in. The user will be confused if that option is presented for sites which will not recognize the authenticator.
The site can store data alongside a credential to be returned to optimize the log in process, such as a site-specified identifier to look up the user credential in a database. That state needs to be synchronized.
No cloud, no synching, nothing. You're fucked if your passphrase is stolen, but that's the tradeoff.
I don't really see a safe way to do what fido was trying to do while letting keys flow about and using their cloud for the original setup with the security we were originally expecting wouldn't have the conveniences they are talking about.. So it seems like more phishing, now for getting an activated device/chrome session.
It's possible to store every key the device has registered, but most devices don't do it that way to keep the cost of the secure enclave low.
Or just get some Yubikeys.
Instead, each website that accepts passkeys should allow you to register multiple devices and probably print out backup codes as well (for the especially important accounts).
If there's no reason to migrate anything then lock-in is irrelevant. Just add more login methods so that when you lose some, you have others.
With backup devices, whenever I upgrade or replace a device, I need to go to each of the 500+ online accounts and register the new device. This is much more work than a quick login to each site via my password manager (which can happen on-demand, only as I need to use the services).
See Show HN post I wrote this morning https://news.ycombinator.com/item?id=33178285
Websites already have a hard time to get users to sign up, so requiring them to enroll backup authenticators (which they won't have) is not going to work. Printing or writing down backup codes is even worse from a UX point of view.
IIRC the spec has a flag to hint that the passkey is backed up (in iCloud or your Google account) so the relying party (website) knows whether backups are mandatory but that means the secret doesn't stay on your device and goes to the mothership. Then I don't see why the spec wouldn't standardize the transfer of secrets from one company to the other.
It would be ideal to set up backup auth before you need it, but you could also do it when you decide to move off Google.
So, not really a lock. It's a vulnerability, though, if you lose access to the Google account for some reason.