Does anyone know the state of the standard wrt this? I know that they planned on doing something about it, just haven't kept up.

https://bitwarden.com/passwordless-passkeys/

Every vendor I see offering a solution has no documented export option at all. Yes, you can use the legacy method to login, but an authentication stream that is not used regularly is one that will break, or will ask for a factor that I no longer have access to (I wouldn't know this because I only use passkeys.)

I also expect that there will be sites that only accept passkeys eventually, even if the spec says you shoudln't.

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/

  > there is no syncing between keys

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.

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

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.

[1] https://fidoalliance.org/specifications-credential-exchange-...

Effectively you have a secret that you are using to authenticate yourself. With pass keys managed by a vendor, you are trusting that vendor to manage your secret. If they are able to give your secret to someone else, then they can no longer confirm who all knows your secret.

I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone.

I'm also sure smarter people than me can surprise me with something, here. But secrets that can be shared historically tend to not be secrets for long.

the spec actually supports this, it's called caBLE

Asked differently, how does this get a vendor out of the picture?

But the FIDO alliance is apparently working on that: https://fidoalliance.org/fido-alliance-publishes-new-specifi...

The issue with hard tokens is that there is only one of them. By design, you can't back up a Yubikey's content to a second token. This means that any time you add 2FA to a new account, you must have all of your hard tokens in your possession to enroll them. This means a "one token on your keyring for daily use, one token in a safety deposit box as backup" approach isn't possible.

Yubico did propose a potential solution five years ago[0], but that proposal seems to have gone nowhere. Until something like that gets implemented, FIDO2 (and by extension Passkeys) requires some form software implementation backed by cloud synchronization to actually be usable for the average person.

[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...

  > When you need to signup for a new service on the go, you can add your backup key when you get to it

Requires you to remember doing that each and every time. Incidentally this isn't that different from just grabbing your keys like the parent suggested. Only it introduces a new variable: time delay. A lot can happen in that time and we all know the reality is that even a diligent person is going to slip now and then. It surely isn't a reasonable expectation for an average person.

every few months I swap 2 and 3, and re-enroll any missing (kept track of with a spreadsheet)

quite annoying, offline enrollment would be considerably better

It's absolutely a goal, since a PIN doesn't prevent your security key from loss, theft, or physical destruction.

That’s one way to look at it: passkeys are just a more convenient form of authentication compared to passwords. Although in my mind you’re arguably not achieving a whole lot considering the security bottle neck is still the same, being the login to your password manager.

I use physical Yubikeys so I’m a bit out of the loop here, but are there any methods for protecting your root password to your password manager in this scenario?

What if you lose your device? Do you install alternate passkeys in a second device? Do you have to do that for every site and service?

By a far and away WORTH the subscription, for me!

In effect, though, 1Password is both something you have (the device with 1P logged in, login requires a Security Key that you don't memorize) and something you know (the master password) or are (typically biometrics can be used to unlock for a period after entering the master password.)

Pretty much all the problems related to passwords are solved by passkeys, having them synced between your devices does not impact that.

They have no interest... in collecting subscription fees? I'm a satisfied 1Password customer, but it's hard to take this claim seriously. What does it mean? They literally get paid. Isn't that the definition of an interest?

Unfortunately the spec authors think this export feature violates the spec and have threatened KeepassXC with being banned by authenticating websites[1]. This explicit support from the spec authors for client banning makes passkeys non-viable to me. The websites I log in to should not be able to restrict what clients I choose to use to manage my own data.

[1] Spec author writes, "To be very honest here, you risk having KeePassXC blocked by relying parties. ... (RPs [may] block you, something that I have previously rallied against but rethinking as of late because of these situations)." https://github.com/keepassxreboot/keepassxc/issues/10407

Exporting/transporting keys seems to be optional on the part of implementors, but my solution has been to use Bitwarden, so I at least get cross platform keys.

One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.

Apple doesn't support it at all anymore; Google only supports it for non-synchronized credentials (which are arguably not passkeys). Bitwarden obviously doesn't either (it can't, as a pure software implementation).

> One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.

Developer of what? There's no competing software solution that supports attestation, and hardware authenticators complement software ones, rather than compete with them.

Not directly threatening but within that frame of mind:

https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation.

With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.

The spec failing to distinguish between these two cases is a major flaw and completely kills passkey viability for personal accounts until they resolve it.

I'm interested in reading more about this. Do you have some links? I did some quick searching of the terms you mentioned and nothing obvious came up.

Some quick bits and pieces from my own searching just now:

Apple's documentation on Passkey attestation is entirely under "declarative configuration", their terminology for mobile device management (MDM) corporate tools: https://support.apple.com/guide/deployment/passkey-attestati...

It is noticeably absent from, for instance, AuthenticationServices documentation: https://developer.apple.com/documentation/authenticationserv...

On non-attestation Passkey responses intentionally send an empty AAGUID for privacy/Apple's belief in the spec's suggestion to send an empty AAGUID:

> iCloud Keychain is one of the few (maybe the only?) passkey authenticator that currently follows the spec and will use an all-zero AAGUID.

From: https://developer.apple.com/forums/thread/739004

On the technical side of limitations of attestation for consumer Passkeys (due to iCloud Keychain sync):

> Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind.

> Attestation was designed to attest to a specific device, exclusively at the point of creation, with a specific set of security properties. It doesn't make sense for synced credentials for a number of reasons, including syncing to devices with different security properties, changes in security properties that happen after key creation, security properties of the sync fabric, sharing the passkey, or exporting to other passkey providers. We're working hard with W3C and FIDO to solve these problems.

From: https://developer.apple.com/forums/thread/708982

(I believe some of the problems being solved in that one in 2022 is referring to how we got the "uvi" and "uvm" extensions to Passkeys, neither of which is in attestation data nor attested in any way, and both designed for a general semblance of user privacy: https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension)

I believe the juiciest quotes I'm looking for are buried in WWDC videos and I can't find a transcript search tool just yet.

> Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind.

On any platform, attestation and "syncing" are effectively opposites. Either you're getting attestation that the auth comes from a secure application and on secure hardware (read: non-exportable in-TPM crypto material), or not.

As usual, it's a tug-of-war between security and convenience.

For example, iOS uses the App Attest service (https://developer.apple.com/documentation/devicecheck/prepar...). On Android, you get it from Google Play Services (https://developer.android.com/google/play/integrity/overview) then the built in key attest service (https://developer.android.com/privacy-and-security/security-...). MS Authenticator does all the legwork and returns the results to you at sign-in time.

On Windows, WHFB has this built in (obviously). On macOS, this comes from Platform SSO (https://support.apple.com/en-ca/guide/deployment/dep7bbb0531...).

The problem is that Passkeys really conflate two separate feature sets:

1. Synchronized password replacements. They _have_ to be represented as accessible clear-text to be synced between devices, at least during transit. So they can be stolen, for example, by malware that scans RAM for keys.

2. Keys that never leave a hardened hardware devices. Since they never leave the device, they can't be synced. But they're completely secure.

Effectively implementations already do that, and the spec could clear things up a lot by clearly defining one profile for synchronizing, non-attestation-capable, discoverable credentials called "passkeys", and another for hardware-backed, non-exportable, attestation-supporting ones called something else.

This technically is true because Passkeys are just a subset of WebAuth.

How well does password recovery work in those scenarios?

You might argue "but if they still have the recovery methods isn't my account only as secure as those" and to that i'd point out that you're still way ahead with passkeys simply by not entering passwords on a routine basis. The recovery methods tend to be two factor as well, just without passkeys as one of the two factors (hence email+password) so still a win over password alone in any case.

Passkeys should be thought of as no different to the old two factor authenticators. I mean that's literally what they are, essentially the latest fido standard that allows devices such as your phone to be a hardware security key in its own right. These always had ways to do account recovery with all the providers.

It's also not a good idea to store the backup at home – house fires are unfortunately a thing, and chances are you might not have time to grab either your main or your backup key.

Shameless plug: Here's one that is "something you know" :) https://github.com/lxgr/brainchain

It derives all keypairs from a passphrase, and rederives the private key from the key handle, similar to "stateless" hardware authenticators.

Please don't use it for anything important – it's a fundamentally bad idea, similar to "brain wallets"; I only implemented it to figure out whether it was possible, and to improve my own understanding of the WebAuthN and FIDO specifications.

If you then purchased passkeys that supported a custom seed, you could then replicate this seed to as many keys as you needed.

There are always security tradeoffs, but this was a mechanism to store something in the real world that had about 115 bits of entropy, as 'Something you know'

It seems like they're synced between devices using client-side encryption, with keys derived from your phone's lock code (typically only 4-6 digits). Is it possible that the passkeys are fully random, but then encrypted with far less than 128/256 bits of actual entropy while being synchronized between devices?

Could it be possible to brute force the keys server-side (IIUC, derived from 4-6 digit pins) with non-excessive amounts of compute? What am I missing?

Or treat it as an opportunity to try to avoid "vendor lock-in"/increase redundancy by using all three to have 3+ passkeys in every service. Windows 11 can act as useful a bridge for bootstrapping all of your keys into a service: register for a site first on iOS or Android, use Windows 11 bluetooth to login via the first passkey, add a Windows passkey, and use Windows 11 bluetooth again to add the third. (Or some combo of that with the Windows iCloud Passwords app and/or Chrome.)

[1] https://www.smokingonabike.com/2025/01/04/passkey-marketing-...

[1] https://github.com/dani-garcia/vaultwarden

I don't want vendor lockin and I don't want proprietary third party cloud based backup/recovery.

Today with totp, I store the plaintext otpauth url and I can use oathtool to spit out codes when needed on my desktop. My phone has aegis, but I don't use any cloud based backup/recovery. I switched from Google Authenticator after they implemented their cloud based syncing to google.

Passkeys kind of take that concept, but make it suck. No backups. Terrible interoperability.

The other day I attempted to create one on my Mac with Firefox. The system passkey popup came up and made me scan a QR code with my iPhone that had to be connected to the internet. Bitwarden (my iOS passkey manager, that part works well) did open, but after selecting the profile to create the passkey in, it errored out. No passkey for me.

I've since disabled passkey support and we have no plans to attempt a new rollout anytime soon.

As far as I can tell the only people that have "successfully" rolled out passkeys are the companies with effectively zero user support and they just refuse to support passkeys at all, so if they don't work for a particular user: whatever.

TOTP is fully rolled out and well supported. Troubleshooting it is "hard", but at least it's possible.

TOTP troubleshooting basically boils down to 3 things:

* Server time

* User Phone/device time(most users opt to use their phone to generate TOTP, but we don't care)

* More than one TOTP saved for a given site(i.e. they didn't replace the old and created a new TOTP shared key) or not saved at all.

Our tech/user support helpdesk can handle this but it took a lot of training. We built special tools. We still get requests from them when they get overwhelmed with the complexity.

Passkey troubleshooting:

* Mobile network, including bluetooth

* Server network connectivity

* Computer/device network, including BT connectivity to mobile device.

Most tech support can't handle that much complexity at once. Shoot, most developers and tech "whiz" people can't either. The error messages one does get, if they are lucky, are very general and not helpful at all(last I checked).

Passkeys are not currently fit for production where you have to support the users. I hope they get there.

1Password is the only client/device implementation of Passkeys that pretty much just works. It saves the passkey in the 1p vault, and the 1p vault can be synced across devices.

It's something else that is unrelated to your password that you have to provide in order to log in, is that not the definition of a factor of authentication ?

Because it's phishable ?

Incidentally, passkeys go into my password manager too. You can probably work the math from there.

(I'm heterodox on this matter, though. I don't believe in the existence of "things you are" and "things you have". I think it's all ultimately just "things you know" and it's all better analyzed in terms of the cost of knowing and proving knowledge, and that the 3-factor framework for authentication is wrong.)

For fingerprints/etc you generally just need a great camera.

I remember those QR codes and needing to use my phone when I tried passkeys a couple years ago when I was on an older Mac that didn't have hardware support for biometrics.

Every since I got a Mac with that support passkey creation has worked fine entirely on the Mac.

Passkeys just feel like a standard written by large tech companies as a flywheel technology to keep me locked into whatever hardware and software ecosystem I'm already in since seemingly no one besides maybe Bitwarden supports exporting them. Which seems pointless, because I don't know of any platform that supports importing them.

I am also getting tired of corporate white knight nerds defending trillion dollar companies telling me that portability isn't a concern.

FIDO/WebAuthn/Passkeys protect you against phishing, because of the origin binding mentioned in the article. On the phishing site, the required credential cannot be generated, and so no matter how convincing it is you can't accidentally give them a credential to forward.

Phishing is what these systems were trying to defend against.

Now if you were to say that the move from plain FIDO tied to a hardware key to passkeys tied to a Google account was a lock-in ploy ---- then I might be more inclined to agree.

It's not an acceptable trade-off. And the answer isn't, "Those third-parties shouldn't be asking for your password and TOTP," because that's not a realistic premise.

To me this seems harder to pull off than a fraudulent password reset (either via social engineering, or a hacked email account). My TOTP fell in the drink a few years back, and some accounts very hard to reset and others were too easy.

I suppose I might want to stop using 1Password someday, but it still has all my passwords as well so I can just fallback to those. And, honestly, only a fraction of the sites I have in 1Password have PassKeys available.

What I hate much more is sites that don’t have passwords and require you to log in via email every time. It drives me NUTS.

Compared to everything else, they are so much of a nicer experience. I despise the "click the link we just emailed you" so much. And MFA is a pain, and still has security issues: https://blog.talosintelligence.com/state-of-the-art-phishing...

I really don't get all the hate for Passkeys on HN...

It feels like the first step in a vendor lock-in strategy. Basically boils down to that. That's essentially my issue anyway.

You can’t copy a passkey to a different password manager, but you can create a new one for the same account, which is usually just as good.