[vngzs]

I can register my Yubikeys on account.google.com (and around the web, e.g., fastmail.com) as passkeys. If you visit the account security page[0] and enable "skip password when possible", then you can log in to Google with only a Yubikey-backed passkey.

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/

[godelski]

  > 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.

[palata]

> This seems like a key failure point

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.

[godelski]

  > 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.

[palata]

> There's a critical flaw in PGP actually.

Passkeys use FIDO2, not PGP?

[michaelt]

> If there isn't some form of automatic backup then I guarantee I will not have a sync when I need it the most.

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.

[kccqzy]

I feel sorry for you, but I've also experienced bugs in password managers that fail to sync plain old passwords.

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.

[godelski]

My point is that we need to address and solve these issues. I agree with you, but if we dismiss them then they don't get solved. The best algorithms are useless if they're too complicated to use and can't fit the reality of an average user. Currently they are hard to maintain for technical users!

[kccqzy]

I don't think solving the syncing problem is as important as giving users clear expectations. The best way to teach passkeys to regular users is to use analogy. Consider the house key: the physical key that unlocks the front door of your house. You can have two keys on separate keychains so that you carry one of them and treat the other as a backup. But if your key is accidentally lost and potentially in the possession of a bad actor, you will want to change the lock on your front door. And if you do that, it is entirely your responsibility to change the keys on your other keychain.

[secabeen]

We do do security by obscurity with our house keys; I don't label my house keys with my home address, while I do label my saved passwords with both the URL and my username. /shrug

[godelski]

I disagree. I think this strategy has been tried for awhile. Decades of security training has improved things but I don't think enough. Email encryption didn't resource get mass adoption until it was a seamless integration like in gmail or icloud. Same with text and phone, via Signal, WhatsApp, and iMessage.

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

[kccqzy]

This strategy has not been tried. Decades of security training has focused on credentials and objects that only exist inside a computer. And because it only exists in a computer, it is too abstract and not tactile enough for regular users to form a mental model. Yubikey is the one chance where we tie digital security to physical security and give people a clear mental model. Earlier you said that

> 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.

[AnotherGoodName]

You can also simply register all your devices individually as a passkey and login with any one of them. Part of the point of the passkey standard was that you can simply have your laptop/phone/etc. act as a Fido2 backed security key in its own right. So if you have multiple devices it's pretty easy to set them all up as your passkeys.

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.

[xyzzy123]

My issue with this is the NxM problem, if you want to do this on 10 websites with 5 devices you need to maintain 50 passkeys.

[kccqzy]

The NxM problem is at least better than the other problem where a website or app requires at most one passkey. WeChat (which is basically required if you need to talk to business associates or friends in mainland China) simply does not support multiple passkeys.

[immibis]

I find it odd to be designing our technology based around ease of use by totalitarian governments.

[AnotherGoodName]

For myself it's really only the Google/Apple/MS accounts i'm using with passkeys so far (and third party sign in/chrome password syncing for the smaller sites) so N is small right now.

Hopefully better syncing comes soon but i'm ok with the current situation for now.

[xyzzy123]

It seems like the obvious endgame is most people will use very strong auth between their devices and Google / Microsoft / Apple and then federate to everything else. All other workflows will become niche because it's not in monopoly interests to build features that make anything else convenient or manageable.

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.

[kccqzy]

> the right law enforcement request will instantly unlock every service you have access to regardless of jurisdiction.

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).

[xyzzy123]

Yep, I agree good outcomes are possible and an e2e sync'd passkey should have better privacy properties than a federated login.

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.

[recursive]

This scares me because I could get fully locked out if my house burns down or something. I like this property of a password manager. This seems to be in direct conflict with the design goals of passkeys.

[AnotherGoodName]

Non-passkey based account access still works. As in i can go into my Google/Apple/MS account settings right now and in the security tab there's a ton of different options you can set.

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.

[recursive]

If I lose access to my password manager, I'd be substantially boned. But I'm less worried about that. It would require me to forget my password, or 1password to get pwned, go bad, or lose data.

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.

[AnotherGoodName]

Account recovery with the big providers that support passkeys is two factor from what i've experienced, eg. sms+email, email+old password or sms+recovery code etc. so definitely a step up from password login.

[lxgr]

Many password managers these days support passkeys and can synchronize them in whatever way you use to also sync your passwords (i.e. a cloud backend, but also a self-hosted Syncthing shared folder etc.)

[recursive]

I can easily export and import my passwords from my password managers and do whatever I want with them. I enjoy having that lever over my subscription.

[lxgr]

There are several subscription-free password managers available that support passkeys, e.g. Bitwarden (self-hosted), Strongbox (lifetime version available), or KeepassXC.

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.

[dvngnt_]

I've been using keypassxc which supports passkeys. It works for github at least

[zikduruqe]

I just use a Trezor One (yes, a bitcoin hardware wallet).

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.

[kccqzy]

I tried setting this up for a non-technical friend who was gifted multiple brand new Yubikeys. The goal is to log in to Google using any one of the Yubikeys with no password. Unfortunately doing so causes Chrome to pop up a dialog requesting a PIN for the Yubikey. How did you solve that problem?

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.

[AnotherGoodName]

Passkeys need to have two factor to count as a passkey per the standard. Otherwise in theory someone could steal your key alone and get in (a big risk).

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.

[kccqzy]

I don't understand why someone stealing my key and getting in is a big risk. They could steal my house key and get into to my house and do far greater damage: grab all physical documents and grab all computers where their full disk encryption key is in RAM.

[AnotherGoodName]

Finding a dropped yubikey and immediately having access to someone’s google account is simply reasonably a bridge too far if that ever became commonplace. Someone decided not to allow that footgun to the public.

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.

[secabeen]

> Finding a dropped yubikey and immediately having access to someone’s google account

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?

[AnotherGoodName]

You should at least need the username but i still totally get the bar being set where it is.

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.