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-...
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.
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.
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.
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.)
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 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?
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.
labadal•4h ago
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.
hiatus•4h ago
supportengineer•4h ago
EnPissant•4h ago
dboreham•4h ago
coldpie•2h ago
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
EnPissant•2h ago
cyberax•1h ago
Steltek•3h ago
> But how can websites know whether its users are using secure authenticators? Authenticators can cryptographically prove certain facts about their origins, like who manufactured it, by generating an attestation statement when the user creates a passkey; this statement is backed by a certificate chain signed by the manufacturer.
How many scummy companies trot out "Let me protect you from yourself" to justify taking away their users' freedoms?
yladiz•4h ago
reginald78•3h ago
One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.
parliament32•3h ago
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.
yladiz•3h ago
parliament32•3h ago
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...).
coldpie•2h ago
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.
WorldMaker•1h ago
coldpie•56m ago
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.
WorldMaker•12m ago
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.
cyberax•40m ago
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.
supportengineer•4h ago
TechDebtDevin•4h ago
dboreham•4h ago
crote•2h ago
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...
hanikesn•2h ago
bitzun•1h ago
johnisgood•4h ago
paulryanrogers•4h ago
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?
johnisgood•2h ago
lurking_swe•42m ago
taeric•4h ago
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.
blibble•4h ago
the spec actually supports this, it's called caBLE
taeric•3h ago
Asked differently, how does this get a vendor out of the picture?
jp191919•4h ago
vngzs•4h ago
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/
zikduruqe•3h ago
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•2h ago
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•1h ago
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.
AnotherGoodName•2h ago
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•4m ago
godelski•3m ago
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.
namro•3h ago
iknowstuff•2h ago
shellcromancer•1h ago
[1] https://fidoalliance.org/specifications-credential-exchange-...
an_d_rew•58m ago
By a far and away WORTH the subscription, for me!
idle_zealot•57m ago
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.