Eg. My Microsoft desktop, my Google phone, my Apple laptop all have passkeys setup individually that allow login to my various accounts such as my Google account.
So they aren't at all synced. They are all from different vendors but they can all login since i set them all up as passkeys. It's easy to do this too. Setup one site for passkey login via phone, go to that site on your desktop and select "auth via phone passkey" and use the phone passkey and then once logged in on the desktop go to account setup and select "Create a passkey on this device". The end result is you have multiple hardware security keys, namely your phone, desktop and laptop.
Hopefully better syncing comes soon but i'm ok with the current situation for now.
This is where the incentives push and is why we're unlikely to see usable or easy passkey sync.
I'm sort of ok with this (it will be a net security improvement) but it saddens me a little to see more of the web come under centralised control.
Most people won't fully understand the implications of this, which will be that the right law enforcement request will instantly unlock every service you have access to regardless of jurisdiction.
Plus lots of secondary effects relating to fed auth providers having increasing leverage over the web in general.
You are conflating the old model of "log in with Google" and the new model of Google syncing your passkeys in an E2E way. The latter is more resistant to law enforcement misuse (not 100%, see All Writs Act in the San Bernardino shooter case).
It's a nuanced discussion because in practice today, email provider is regarded as ultimate source of truth regarding identity, except for high security domains e.g. where money is involved (banks, crypto) and it's economically viable for recovery to be high touch.
So having access to a user's email is the first "golden key".
Second is OIDC / social logins.
Third would be passkeys / stored passwords / an unlocked device.
My guess about the future is that OIDC / social login will prove to scale and grow better than direct passkeys in most instances. It's a better, more fully developed model for thinking about and managing identity lifecycle, passkeys themselves are a low level primitive by comparison.
Users will understand it (social login) better, providers will support it better (partly because corporates don't have any way to centrally manage passkeys at scale, nor should they) and finally because of the fallback / recovery problem for sites using passkeys.
Backup codes, sms phone recovery, alternate recovery email are all there in all of the above.
It's no different to forgetting your password/losing access to your password manager is it? As in i've literally at points lost access with passkeys (i only had 1 at the time) and the way i got back in was very straightforward and no different to losing access to a password manager. I got an email and typed my old password and i got back in and re-setup my passkeys.
The way I assess risk, that's less likely to happen than I am to lose my passkeys.
If I'm using passkeys but can recover my account with SMS, then why am I using passkeys? That sounds like the weak link of security. I'd rather use passwords, where I can understand what the password consists of rather than passkeys if I'm not getting an increase in security.
It's unfortunately not quite the same level of portability as passwords, as I don't think there's any standardized export/import format yet, but these options are significantly better than Apples's and Google's closed ecosystems.
I back up my 12 word seed phrase, and then I can restore any and all my TOTP/FIDO/passkeys with another one if needed.
Searching online I found an answer on Stack Overflow stating that a PIN is required in this case: https://stackoverflow.com/a/79471904 How did you bypass it? I also find it idiotic that it is required. A PIN is just a password in another name, so we are back to using Yubikeys as the second factor in 2FA rather than a password replacement.
You need to buy a newer Yubikey with biometrics to make this work. I assume you have an older Yubikey and Google is getting to the standard by asking for a PIN.
I have a https://www.yubico.com/products/yubikey-bio-series/ and it works with Google exactly like you want it to, no PIN required. It's completely understandable to require a PIN if you don't have one of these though.
It’s no inconvenience though since the yubikey with a button to press and a yubikey with a biometric button to press work the same.
Is that how it works? A dropped house key essentially has a second factor (the address of the home), but if you have someones Yubikey that can be used for Google, is the Google Username stored in the Yubikey and accessible to the finder?
Like you can argue a dropped house key is similar to a dropped yubikey but i'd still give some benefit to the dropped house key involving real world attempts on locks with appropriate social suspicion on that if seen vs a dropped yubikey allowing anonymous attempts.
> there is no syncing between keys
This seems like a key failure point to me and why I've been a tad resistant[0]. If there isn't some form of automatic backup then I guarantee I will not have a sync when I need it the most.There is a similar problem even in OTPs. I switched phones not too long ago and some OTPs didn't properly transfer. I actually lost some accounts due to this, luckily nothing critical (I checked critical things but it's easy to let other things slip). The problem is that registering a new OTP removes the old ones. In some cases I've used recovery codes and in others the codes failed. IDK if I used the wrong order or what, but I copy-paste them into bitwarden, and I expect this is typical behavior.
99% of the time everything works perfectly fine. But that 1% is a HUGE disruption. With keys, I would even be okay if I had to plug my main key into a dock to sync them. Not as good as a safe, but better than nothing. I feel like we're trying to design software safes like we design physical safes. But if you lose your combo to a physical safe you always have destructive means to get in. With digital, we seem to forget how common locksmiths are. Googling, numbers seem kinda low but I'm not in a big city and there are at least 4 that I pass by through my typical weekly driving. So it seems that this issue is prolific enough we need to better account for actual human behavior.
[0] Don't get me wrong, I love them but I'm not willing to not undermine them via OTP creds because I need some other way in.
As I understand things, passkeys come in a few different varieties.
You can buy a yubikey if you want the credential tied to one specific physical device. Figure out your own backup strategy, such as spare yubikeys or printed recovery codes or whatever.
Or you can use apple/google/microsoft if you want your passkeys backed up to your cloud account. This means passkeys are basically the "Log In With Google" button, but with extra steps.
I feel like if I must choose between a 99% reliable syncing solution, and a non-existent automatic syncing solution that requires manual syncing, I would still choose the latter for its mental simplicity.
My point is that training doesn't seem to be effective to the general population. Frankly most people don't care. As we both probably know a big part is likely not knowing the importance
> The best algorithms are useless if they're too complicated to use and can't fit the reality of an average user.
I agree. So get rid of needing to understand algorithms and simply require users to understand passkeys in relation to their house keys.
> This strategy has not been tried.
Has your work never given you security training?Have you tried to convince your friends to use messaging systems like Signal? What about PGP?
> understand passkeys in relation to their house keys.
Except they aren't the same thing. For exactly the reasons I was discussing. How often are locksmiths helping people get into their houses? What about their cars? It's a lot more common that you think.There are plenty of cases where I know that people have misplaced Yubikeys. They might have a spare Yubikey. Or the equivalent to finding a locksmith is to log in with a non-passkey method. It's fine and in fact better if logging in without a passkey is considered an unusual fallback.
> A passkey synced using iCloud or Google account does not break that model
Yes, yes it does. Have you seen how hard it is to recover these accounts? There's not uncommon HN posts that do get these solved, but only then by high visibility. A method most people do not have available to them. > Or the equivalent to finding a locksmith is to log in with a non-passkey method
Sure, it is just that the backup methods end up undermining the security key.Both of these were mentioned in my post you originally responded to: https://news.ycombinator.com/item?id=43988957
Actually it is a feature. The whole point of the Yubikey is that you can't extract the key. Syncing keys would mean extracting them, which would defeat the purpose of the Yubikey.
Now I am not saying that it is a feature you want. That's why there are other kinds of passkeys. My point is that it is not a flaw in Yubikeys, it is by design.
> Actually it is a feature.
There's a critical flaw in PGP actually. If you reply to any PGP encrypted email with "sorry, I couldn't decrypt" you'll, with high likelihood, get the cleartext version of the email soon after.The joke is quite old and part of what I'm pointing to. Security doesn't work well if it isn't very usable. At least this is a bit better than secure communication, but it isn't as huge of a difference as it might appear.
The biggest boon in security has come due to making these tools easy to use. That's from decades of experience is realizing you can't get everyone to be technical.
If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login).
Multiple yubikeys are required if you would like to have backups; there is no syncing between keys.
For support matrices, see [1].
[0]: https://myaccount.google.com/security
[1]: https://passkeys.dev/device-support/