However, this negates the primary stated objective of passkeys, removing the possibility of users being phished, so I'm not sure how long that will remain the case everywhere.

I've also encountered sites that have a login with passkey prompt that then turns around and asks for TOTP 2FA or email confirmation anyway, which to me seems to negate the primary customer benefit of passkeys...

My non-technical friends are extremely confused by passkeys and if they should use them and how to use them and I honestly don't have very good answers. It is a mess. I don't believe an inherit mess, but one created by the companies and projects trying to take advantage of the new system.

How do you generate a new key if you need one? Same process as a password reset. Does it prevent session stealers? Not at all.

Its "benefit" is grandma can't read it to an attacker. OK, well can grandma click a link and have a session stealer bork her life instead? Yeah, and attackers know that and just shift methods. Session stealing isn't a sophisticated attack, and so all that's being done is shaving a cost on PW resets in the interest of shareholder value, at the cost of security theater and locking up your keys in a single domain that holds control over our access to everything.

(But you're not going to lose it, because you use a password manager, and the passkey will be stored there and synchronized to all of your other devices.)

The weird part is that password managers provide no way for you to copy and paste your passkeys. To present a passkey, you have to use a password manager. This makes it impossible to copy and paste your passkey to the wrong person (someone trying to trick you).

Major password managers don’t even allow you to export your passkeys to a file that you can read/backup yourself. Instead, the password managers each have their own finicky app-to-app mechanism for transferring passkeys from one password manager to another. (I think all the password managers kinda like that lock in.)

Finally, note that for logging into your password manager itself, you'll always require something outside your password manager to login, probably a password, but possibly a YubiKey; your choice. (It's your one "last password," as they call it.)

https://danfabulich.medium.com/passkeys-are-just-passwords-t...

P.S. It's past time to move off of LastPass. LastPass lost all of your passwords again last month, just like they did in 2022. The most similar service is 1Password. If you like LastPass, you'll like 1Password about the same, but 1Password hasn't had multiple terrible security breaches.

I can safely write down a password on a piece of paper and keep it somewhere phyisically safe.

Passkeys and 2FA are a usability nightmare if you need to recover, or all the security vanishes if you put usable recovery mechanisms for the passkey or the second factor.

> Passkeys need a marketing campaign and UX overhaul. I’m a technical guy, but I really don’t understand what the fuck is going on when I use a passkey. All I know is one day it appeared as an option and it let me login to things. I don’t really understand where it lives, what device it’s tied to, how scanning a QR code on Google Chrome on my phone magically logs me in, etc etc.

The user was not educated on this. Hacker News is the top 1% of computer power users. You gotta understand to someone’s grandma or mom or brother who works in real estate none of this makes any sense nor will they educate themselves on what it is.

https://news.ycombinator.com/item?id=46301585#46303892

Registration generates an asymmetric key pair between your passkey, and the website. Login is the usual challenge/response process. The biggest step forward is phishing resistance. A fake login page can relay a TOTP code, but not the passkey challenge/response.

I've seen the same on Android too, and I think there's a difference in how Chrome and Firefox are handling the requests.

Then you get in to cases like a Microsoft Account. You need to use your account to log in to the device that has the passkeys, so the workflow never works properly and you have to fall back to another method.

Amazon is another one. If an app like Libby redirects to Amazon, I get a different, passkey-less password prompt, so I need to have a password readily available.

It's great when it works, but honestly 1password with straight up username/passwords is probably just a better UX in the end.

Honestly, this is one of the two things that make me hate passkeys. The key management is a high-friction pain in the ass.

This is on top of the confusion around enrolling passkeys in your device and synchronizing them

I am a big passkeys fan, and use them on every service I can, but they leave a lot to be desired in terms of user experience. Not sure all of them are solvable, either. The platform vendor side can be fixed: vendors can better integrate with each other to make your passkeys available on every device. But, the issues with how they work across sites and applications is probably not solvable

And now I have another thing I need to carry everywhere.

Software vendors continue to refuse to support, or even accept the existence of, this entire class of use cases for regular consumers (they are, however, more than happy to milk enterprises on convoluted implementations of those).

how to use cross-device? either use some password manager that supports it (apple/google/1password/keepass/etc support it), or use device that you have on hand most of the time - phone. when the passkey pops up - point your camera and scan the qrcode - you are done. otherwise use dedicated device like yubikey or similar.

really not sure what is hard about that to understand. i'm using android and chrome, so i can use the password manager in chrome, or my phone to scann the qrcode.

my country is using similar authorization for government "profile" (mobywatel - poland) that has similar to passkey implementation. you download the app on your phone, login via login+password (or other), download the certificates, and from now on you can point your camera on qrcodes to login to government websites; it requires pin/code or biometric confirmation on the phone - same as passkeys.

I spent a long time working in the network security field, and you speak truth. The perverse thing about it is that security people should care a lot about usability. If the scheme isn't usable enough, people will figure out how to bypass it or aspects of it.

The technically weaker security scheme that everybody accepts is more secure than the technically stronger security scheme that everybody tries to bypass.

Plus, that doesn't have the negatives/limitations of passkeys.

It’s not that difficult. Spend 10 minutes researching the topic and you’re fine. Passkeys are so much more convenient than having to use passwords. When implemented right, it’s literally one click from opening the login page to being signed in. On all of my devices.

As is, I had to either:

- Keep both on me, and add both - I am at risk of losing both at the same time

- Keep one one me, one in a safe - I have to keep track of which device I've added to which service, and periodically take the backup one out of the safe and iterate through the "new" services

I was never satisfied with either approach, so I ended up with an OTP app with backups.

or shared passkeys (where the private key can be synced through something like a cloud service across your devices, see Bitwarden, iCloud)

Until I can tell Grandma to "go down to Walmart and ask the man at the electronics counter for a Yubikey", we still have a few issues.

(No. Ordering online is *not* a valid option in this scenario. If I want to order a Yubikey to this address at this exact moment in time and space, Amazon won't deliver one to me for at least six days at the earliest, based on their rural delivery estimate. Replacing a key is basically impossible.)

You can have 7 passkeys. You can have 14.

The real failure of passkeys (emphasis on the s!) is that people think they must only have one.

In my opinion it's a bad plan, because it elevates certain devices to privileged status, if you lose your phone you are hosed.

Passkeys should be allowed to be synced between devices and stored on password managers in the cloud. I am making my own password manager for my personal use, but have not delved into passkeys.

The issue isn't what passkeys _are_ (e.g. explaining they are like public/private "ssh keys" and hoping that type of explanation ends the confusion).

Instead, it's the workflow around passkeys. The websites show very confusing dialog popups and choices that a lot of normal people will not understand. This is a good article with screenshots showing the confusion: https://arstechnica.com/security/2024/12/passkey-technology-...

I have senior citizens asking me about passkeys because their bank and medical websites keep reminding them about switching to passkeys every time they login into their accounts. My recommendation to them is not to do it unless they have a simplistic single vendor setup such as only Apple iPhone and MacBook with iCloud Passwords app. If instead they have a mixed Windows + Apple setup with 3rd-party password manager, they could accidentally put a new passkey into the os or browser instead of their external password manager and not realize what has happened. This happens because the different parties implementing passkeys all have different agendas that suits their interests and that's what makes the workflow confusing for normal people.

Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound, the private key held in the TPM or secure enclave or whatever other security chip, mathematically non-exportable. Storing all your private keys in a cloud vault still leaves you exposed to potential credential theft if your vault gets compromised.

Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).

With the exception of Github, and banks.

> But you're not going to lose it, because you use a password manager, and the passkey will be stored there and synchronized to all of your other devices

That's just wrong. I use android, my partner uses ios. If he creates the passkey in safari, it's not going to get synced over to my phone. And that's just the first of the family sharing passwords issues. Same person issue is also present if somebody uses an iphone and a windows laptop, or chromebook.

It doesn't help that all modern browsers eagerly try to step in and offer their implementation of passkeys for logins, and they're not featured enough to support the type of shared access or synced access many people would expect from a password manager. How useful is your firefox passwords on an iphone? Or Mac OS's keychain I use as a daily driver on my windows gaming desktop?

> Major password managers don’t even allow you to export your passkeys to a file that you can read/backup yourself

This is wrong. Every single major password manager supports export. Lastpass, 1password and bitwarden all do that.

> It's past time to move off of LastPass. LastPass lost all of your passwords again last month

That just isn't true. Last month, their third party customer support portal was breached. That did not involve passwords.

And Windows, you need Bluetooth enabled on both devices, on Linux you need Chrome (and presumably bluetooth enabled). It makes you scan a QR code.

Most providers continue to offer email-based recovery in the case that the end-user loses access to their primary factor, regardless of whether the primary factor is a password or a passkey.

And email based account recovery does not make the security advantages of passkeys disappear, which are:

- credential that's guaranteed to be unique

- credential that's guaranteed to be strong

- credential that cannot be phished (due to cryptographic binding to the domain at the time of credential creation)

- changes the incentives for compromising servers (there's nothing worth stealing from the server -- only public keys)

- if/when an app/website transitions to retiring password-based authN, then it will entirely eliminates credential stuffing attacks

And if the account recovery scenario in question is your Gmail or Apple account, then you would need to go through their account recovery flows regardless of whether you were using a password or a passkey:

https://support.google.com/accounts/answer/7682439?hl=en https://support.apple.com/en-us/118574

On Windows, I hate them. They always push me towards using a PIN instead of my Yubikey or password.

This is why I don't bother with these if they have a weaker workaround, which will be open to remote hacking.

those that don't have this built-in (eg. KeePassXC) recommend using Dropbox or some external sync mechanism

but the keys are stored in a file, which you can back up.

> all the security vanishes if you put usable recovery mechanisms for the passkey or the second factor

no, not at all. it still gives you better UX, because when you use the passkey you know it's the site you want to log in to. (because there's mutual authentication.)

Passkeys can too, but there it's even more obfuscated than with 2FA.

Already you're off-base. Of course it works when your devices are homogenized, but very little folks work that way. Some people have a Windows computer using Brave, an iPhone using Safari, an Android device using Chrome, and a work computer with its own hardware/software limitations and partitions.

Of course it works when your ecosystems are not diversified. Problem is, most people are.

If technically-motivated individuals can't be assed to switch away from passwords, then imagine how normies feel. I fully understand why most people choose passwords instead.

So far only Nintendo has been absolute assholes about requiring specific passkeys, but that's maybe the least assholish thing Nintendo has done.

also appreciate your attitude, better than "I work in tech for xx year, i don't understand yy, so yy must be bad."

I can have the most complex password and create a passkey, but a windows machine could allow a 4 pin digit to access the passkey.

If the website didn't implement a "lost password" button then that says a lot more about the website than it says about passkeys.

sure there are some issues sometimes (outages and others), but most of the time they work like charm and solve a lot of issues with login+password issues.

- [0] https://play.google.com/store/apps/details?id=pl.nask.mobywa...

- [1] https://dane.gov.pl/en/dataset/2919/resource/43845,mobywatel...

Now, is that the official stance? I don't know; but it's _absolutely_ what every current implementation suggests the companies deploying this stuff want.

You can make passkeys better. Like me, you can install a well-funded password manager (well-funded, because it needs the engineering effort behind it to keep up with the ever-changing passkey apis on every platform in the world; screw up and oos, can't log in today!). Then you have one passkey per remote service, and just have to make sure 1password is _always_ installed and perfectly integrated. Easy!

It already falls apart for regular interactions like "Can you send me the Netflix password?"

It's a nice simplifying step to talk about password managers here, but in the majority of the cases this won't be handled by a password manager, but rather by the device operating system, and the device manufacturers really like that lock in.

They're also in an especially good position to abuse it, because they now know every service that you authenticate and the webauthn "attestation object" field lets them set up a side channel with those services such that they can sell additional information about you.

Some people will tell you that the attestation object is not used in the consumer passkey system, so there's no way for this abuse to occur, but since it's usually going to be the device manufacturer who controls the password-manager-like component here, and they're the ones who stand to profit most from this kind of abuse, I think we need stronger guarantees than "the spec says you shouldn't do this unless the user is your employee and you paid for their device".

Until they fix this, I'm sticking with my mess of TOTP authenticators and yubikeys.

Passkeys lock into a specific device and seem easy until you need to use another device.

But instead of being a credential you own and control, across what could even be a local password manager, it's one password to everything. Maybe it is more secure than a regular password in some cases but it largely seems like a worse fix than existing tools for a problem that has better solutions.

ITS NOT SIMPLE AT ALL

1. The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing).

2. Majority of industry players shared the vision of a credential which is available across the platforms and browsers

3. The vision for collaboration never materialized so everyone went their own way to implement it. Examples would be google rolling out browser (Chrome) managed authentication which led to this situation where even on the same machine you have to remember which browser you used to create the Passkey credential.

4. Interestingly enough the earlier popular name was WebAuthn, Apple started calling it Passkey on fly, given Apple's popularity everyone just caved in.

5. My personal interpretation is that in some sense Apple wanted to be the default password manager on Apple devices.

6. This is when all password manager companies jumped in strongly to save their business and the protocol went into a direction where you can use your existing password manager to store the credential/Passkey as well

Personally its a mess, the phishing resistant aspect has its own benefits though. If you are using it with security in mind then my recommendation would be to use a hardware backed security key with NFC enabled. Everything else is pretty much lipstick on pig, they are worse than passwords in some sense from usage perspective.

Why is there so much misinformation nonsense around passkeys?

I think the reason is because I've anchored passkeys into my understanding of how 2FA works, and the pain of migrating 2FA from one phone to another.

So, I don't want to bother with it.

Most providers continue to offer email-based recovery in the case that the end-user loses access to their primary factor, regardless of whether the primary factor is a password or a passkey.

And email based account recovery does not make the security advantages of passkeys disappear, which are:

- credential that's guaranteed to be unique

- credential that's guaranteed to be strong

- credential that cannot be phished (due to cryptographic binding to the domain at the time of credential creation)

- changes the incentives for compromising servers (they're nothing worth stealing from the server -- only public keys)

- if/when an app/website transitions to retiring password-based authN, then it will entirely eliminates credential stuffing attacks

there's. it depends on how the site implemented passkeys.

I'm using multiple devices and passkeys via keepassXC. I haven't lost access or even got locked out of any accounts.

but it's like 2FA, and almost all sites have a clean fallback (backup codes) for 2FA.

A passkey doesn't give up anything compared to a password, and is in fact much much easier to handle, IMHO. I have kept all of my private SSH keys in secure hardware for a decade, so perhaps I'm more used to carrying a physical key than others, but IMHO it's all better, all around.

We should eliminate passwords, and that has nothing to do with remote attestation, age verification, or anything like that.

For 20 years, I've only known two to three passwords at any time, and those are login passwords for separate boxes or corporate/home accounts. Beyond that, hardware access should solve everything, and I shouldn't have to type any passwords anywhere. Every account needs granular credentials, not shared credentials, but no user should have to memorize passwords beyond one per work domain.

That's a red flag to me. It's enough that phone backup systems go out of their way to prevent you from accessing your own data, too, for unexplained "sekhurity" reasons.

> P.S. It's past time to move off of LastPass. LastPass lost all of your passwords again last month, just like they did in 2022. The most similar service is 1Password. If you like LastPass, you'll like 1Password about the same, but 1Password hasn't had multiple terrible security breaches.

That's the most annoying thing about password managers, and a major reason I still don't use them: there exists no password manager that is cross-platform (desktop/mobile in particular), local-first, and isn't sketchy or enshittified or otherwise on HN's current "don't use it, use <whatever> instead" list.

For core security tool class, that doesn't inspire confidence.

Exactly the sort of behavior that will suck in the unsophisticated user, and then leave them with no options when it fails.

That sounds like an Amazon problem. For 40 USD, yubico.com says that it will deliver a shipment on the next business day to this rather rural house I see in the middle of Foothills Road in Newman Lake, Washington.

Also:

> Replacing a key is basically impossible.

If you know that getting next-day delivery is dreadfully difficult, then order a handful to have as spares. "If you can reasonably afford it, always buy more than one." is solid advice for just about every important thing that you are likely to break or lose.

Sounds good until you realise theres no way to transfer/back them up and you are limited to 100 [1] (previously 25?).

Personally my password manager has almost 4x the entries so hardware passkey solutions are a joke leaving users with single option - upload their keychains to ms/apple/etc clouds where they can be requested by any gov under the sun for x reasons.

[1] https://support.yubico.com/s/article/How-many-accounts-can-I...

The device bound model also completely falls apart in the enterprise, fails to address shared devices and shift workers where employees share the same PC under the same OS profile, now you're back to needing good old fashioned SSO w/ physical MFA (Yubikey) to attest who the user is in addition to attesting the device itself.

Before synced passkeys, the actual standard is a unique key pair per device. The key pair on my phone shouldn't be synced to my laptop, my laptop should generate it's own key pair.

There. You just violated the premise of his point, that you use a password manager that syncs to all your devices.

The passkeys sync just fine between iOS and Android on our devices using 1Password.

They all support exporting passwords, but, check your CSV; you won't find any passkeys in the CSV export for Apple, Google, Microsoft, Mozilla, 1Password, or LastPass.

(Bitwarden, Proton Pass, and KeepassXC do support exporting passkeys to CSV, which undermines the phishing protections, at least somewhat. It’s possible to trick you into exporting your passkeys from Bitwarden and sending the file to an attacker. It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.)

> How useful is your firefox passwords on an iphone?

Did you try it? That's the primary feature of the Firefox app for iPhone.

(Especially since the Firefox app for iPhone is just Safari's WebKit wearing a Firefox disguise.)

> Or Mac OS's keychain I use as a daily driver on my windows gaming desktop?

https://apps.microsoft.com/detail/9pktq5699m62?hl=en-US&gl=U...

> With the iCloud for Windows app, you can access photos, files, passwords, and other important information from your iPhone or other Apple devices on your Windows PC.

When Apple's your password manager, you use Apple's password manager app to synchronize passwords and passkeys.

It would, if the people implementing it weren't all so obsessed with pushing their own platform-specific solutions over enabling open standards. LastPass works fine on Android, iOS, Mac, and Windows, but each one of those platforms defaults to saving passkeys in their own platform-specific store unless you jump through hoops to specifically save them somewhere else.

If my phone's camera is broken but both devices have bluetooth, it can do the handshake over bluetooth.

If I'm on someone else's computer and I want to use a passkey on my authenticator on my keychain, I'll just plug it in and then tap the button on the authenticator.

Meanwhile, if I logged in with the password and the account only has a password then they have a full copy of my entire authenticator to the account. With the passkey, once the session is invalidated the access is gone.

as others mentioned, there's BitWarden (cross-platform, self-hostable), but if you want something simple there's KeePassXC (and you can put the store file on a dropbox shared folder)

But don’t log in to important accounts on a public computer, like ever, unless it’s a dire emergency.

I like it because I can use discord on even a pretty untrusted computer without providing it any credentials or access to my passkey, and then later when I'm done I can revoke the session.

I ask because I'm curious about others' practices and desires here, not with any promise of a better solution!

That's the real failure? I think the real failure is that people must have _more than one_. I thought so hard to add all my credentials to 1Password. Now people tell me I should use a Yubikey (or better two or three of them). What do you think, I'm going to register a couple of hundred accounts times three for something I already have (my password manager)?

The real advante in passkeys is in allowing me to log in into a service on a foreign device without typing [my password], which is (honestly) something now sane person should ever do.

Let's say I have a new account and a single Passkey in the TPM of PC1. I want to log in from PC2, too. How can I do that? (I know there is some trickery with Bluetooth, but I haven't seen anything supporting it, and desktop PCs usually doesn't have Bluetooth connectivity.)

AFAIK some browsers can do some magic to use a Passkey from your smartphone on a PC, but you need to log in to the same browser-sync account from both device (which brings back us to the same issue).

Also the whole thing becomes a mess when you change devices. You need to log into all the services you have ever used to delete the Passkeys from devices you no longer have, and you need to add a new passkey from a new device you bought to all the services you use.

  > Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).

1) When I buy a new device, how do I create 2000 new Passkeys for that device?

2) Can I still do that if I don't have access to the old device? Maybe it was destroyed, stolen, or lost.

3) How about if the new device is from a different vendor than the original device? E.g. switching from Apple to Android?

  > Passkeys should be allowed to be synced between devices and stored on password managers in the cloud. I am making my own password manager for my personal use, but have not delved into passkeys.

If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case.

What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple.

The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.

This is a misconception. A particular service can choose to enforce those class of passkeys, but most don't need that and shouldn't.

Passkeys are primarily meant to replace passwords and be hard (but not necessarily impossible) to exfiltrate.

The key difference is during normal usage you don't have to type the secret in anywhere, it's strictly asymmetric, so a unwitting user is far less likely to get fooled into accidentally leaking the actual credential.

So your account is now tied to a physical device; great, but the device is dead, or you own a dozen devices, now what? Each vendor has their own idea about what THIS means. Heck I have a couple that allow, max, a single Passkey at a time.

1. All passwords stored in password manager. 2. Login with password manager when logging in for the first time on a device. 3. Combination of OS and site/app notice that no passkey has been created for this account and offers to create one. This is presented to the user as “setting up the current device for password-less log ins.” 4. OS negotiates with site/app to install the passkey and use it for future log ins on the device.

It’s presented to the user as a convenience clearly tied to this device.

…but you still have your text password stored in the password manager’s servers…

If your system requires any basic intelligence or interest scrap it and go back to the drawing board because you just lost your customers.

No major bank revokes your password when you setup a passkey, either.

If you lose your bank passkey, (e.g. if you put it in the wrong password manager and you can't figure out where it is) you can just sign in with your bank password.

In the worst case, banks actually don't make it very hard for seniors to reset your password/passkey; just show up at a branch with photo ID, your bank card, and your PIN, and a teller will help you reset your credentials. They do it all the time.

And, remember, seniors could also put a randomly generated password into the wrong password manager. In that case, they'll either have to reset their password, or they'll have figure out what they did, retrieve their password from the OS password manager, and transfer that password to their preferred password manager.

The exact same story applies to passkeys, except, because passkeys can't be copied and pasted, you'd have to figure out how to use the finicky app-to-app transfer system ("Credential Exchange Protocol"). That's probably too complicated for most seniors, so falling back to a password is almost certainly their best bet.

And many sites block paste from password managers. Passkeys have so many ways to do them wrong that we're going to see all kinds of new and exciting failure modes that lock you out of your account in the future.

I had the same frustration, I ended up with Keepass, the store is a open spec db[0] that has several clients, I use it across windows, android, and Linux without any issue and just sync with your favorite file sync tool.

0 - https://keepass.info/help/kb/kdbx.html

I've used pwsafe for years now. I think it checks off all your boxes. Works on desktop and mobile. Local-first but allows cloud if you really want to. No ads or enshittification. Bonus: Open Source. Other Bonus: Not owned by BigTech or LittleTechThatValuesMonetizationOverSecurity

    it's one password to everything

Passkeys are never reused. Even for the same person, they are always unique across websites, and across devices.

All password managers support passkeys.

Both apple and google allow exporting your existing passkeys to third party password managers too.

Also each website gets it's own unique public key with passkeys. It isn't a single credential

You're literally arguing a strawman

I think Bitwarden is on HN's current happy list. (I just use Apple iCloud myself.)

Allowing passkeys to be exported to a plaintext file undermines the phishing protections, at least somewhat. It’s possible to trick you into exporting your passkeys from Bitwarden and sending the file to an attacker.

The major password managers say that this is the reason they don’t allow exporting passkeys, and it’s not false, but they’re also making it harder to switch password managers, which may be their ulterior motive. (You can’t even import those exported passkey files into any of the major password managers, which they would be incentivized to do, if those smaller players had significant marketshare.)

It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.

How does this work, exactly? Does you cloud password/key manager allow syncing to the YubiKey?

Or do you register a second passkey that you store on the YubiKey whenever you create a passkey?

If it is the latter, do all services that allow passkey authentication also allow registering multiple passkeys? How many?

> could do two backup YubiKeys [...] keep one YubiKey in a safe deposit box

If you register a new passkey on the primary, do you then have to take the backup YubiKey out of the safe deposit box to put it on it as well?

I haven't seen this kind of question answered when sites prompt me to use passkeys instead of passwords.

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

https://news.ycombinator.com/item?id=47189749#47193048

My read on it all is that FIDO is stuck in some sort of groupthink. They don't feel the boots on the ground confusion around passkeys being opaque. They only care about phishing and being called "insecure" and don't care about anything else. Hence why WebAuthn has additional weird anti features like AAGUID for provider authentication.

Another one of those ridiculous threads is saying you gotta have support for nonsense like user presence verification.

https://github.com/keepassxreboot/keepassxc/issues/10406

Quite complicated to get it all setup (definitely not for non-technical users), but both are GPL and I now have all my passwords available with hardware protection (yubikey on desktop, secure enclave on iOS) in all locations.

Multiple pieces of software vying to be your passkey provider, often using dark patterns so you don’t realize you’re making a choice, and not using the term “passkey” so people are using the technology without knowing what it is or how to research it.

Kind of reflects the state of the web today, where every company wants to be your intermediary in every interaction, from making a purchase to transcribing a meeting.

You're right that all of the major password managers like their lock in. The Credential Exchange Protocol is just barely good enough that OS vendors can say they "support" it, but tricky enough to find that ordinary users probably will never try it. (Not to mention that it doesn't even work yet on Windows or Android.)

As for attestation, the good news is that Apple always returns 0s for the attestation ID (because Apple, like you, opposes it as a side channel), and so any public site/app that insists on attestation would reject all Apple devices. This gives smaller password managers like Bitwarden sufficient cover to 0-out their attestation as well.

I currently only use passkeys for a few websites that have awkward password login workflows or do not autofill properly from my password manager. I just have a single passkey for each that is synced via Bitwarden. Currently, I see passkeys as using an electronic biometric lock on the front door while passwords are still regular locks on the backdoor. The biometric lock on the front door does not do much for security when the backdoor still exists and I have come across very few websites that support only allowing passkeys. And those that do still run into problem 2 listed above.

(I.e., Yubikeys and other USB sticks.)

It works fine and it a no-brainer to use.

The problems start when vendors start trying to shoehorn their shitty cloud auth services into WebAuthn.

I’m a little afraid that hardware tokens are getting lost in all the passkey marketing BS. At least they continue to work for now.

https://f-droid.org/en/packages/org.liberty.android.freeotpp...

No need to be a part of an 'ecosystem' to use a password manager or passkeys.

Nobody fucking knows.

>1. The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing).

This is incorrect. The idea was to provide a phishing resistant primary factor that could compete with the usability of passwords to the point that consumers would actually want to adopt it.

>2. Majority of industry players shared the vision of a credential which is available across the platforms and browsers

This is correct/accurate.

> 3. The vision for collaboration never materialized so everyone went their own way to implement it. Examples would be google rolling out browser (Chrome) managed authentication which led to this situation where even on the same machine you have to remember which browser you used to create the Passkey credential.

IIRC at least Chrome's default on Apple platforms is to save to the Passwords app by default. There are then multiple fallback options in the case that the user isn't using the default credential provider -- ultimately falling back all the way to cross-device passkey sign-in (the QR-code initiated sign in) or Security Key.

The security engineering behind the QR-code cross-device sign-in stuff is interesting: https://www.corbado.com/blog/webauthn-passkey-qr-code#4-pass...

That said, I strongly agree that fragmentation of where passkeys get saved is super confusing and I wish there:

(a) was stronger guidance from the FIDO alliance on both educating users that it's totally fine to have multiple passkeys across different ecosystems (e.g. one in Apple, one in Google), and;

(b) that all the credential managers could figure out a better way to place nice together and make it super clear to the end-user where a passkey is getting stored, what context it's for (e.g. personal vs. work), and actively help them store it in the right place (which might be different credential manager app for personal vs. work!).

> 4. Interestingly enough the earlier popular name was WebAuthn, Apple started calling it Passkey on fly, given Apple's popularity everyone just caved in.

This is incorrect -- passkeys are not just another name for WebAuthn. If you go back and look at the original definition Apple gave for the word passkey, you'll find that it was meant to be a discoverable WebAuthn credential that syncs across a user's devices with end-to-end encryption. There was a bunch of industry thrash around the definition, but it seems like the original Apple definition has largely stuck/settled now, and when passkeys don't sync they're typically called "device-bound passkeys" rather than just "passkeys".

>5. My personal interpretation is that in some sense Apple wanted to be the default password manager on Apple devices.

If you go back and watch the original passkeys announcement from Apple, their stated goal was to create something that is both a better user experience and more secure than passwords. By "better user experience", they meant the act of creating credentials and then repeatedly using those credentials (logging in).

Part of actually achieving that goal means there needs to be something that "just works automatically out of the box" which means there needs to be a built-in credential manager. That said, Apple credential manager had already existed for many many years by the time passkeys came around. The only thing that changed was instead of being solely accessible from inside System Settings (which was hard for the average user to find), the functionality moved into a standalone Passwords app.

>6. This is when all password manager companies jumped in strongly to save their business and the protocol went into a direction where you can use your existing password manager to store the credential/Passkey as well

I think it's a huge positive that all the password managers jumped on board, and that they could jump on board (since WebAuthn is an open standard). I think this is a good thing for consumer choice and for overall adoption and perception of passkeys. A lot of folks (including on this thread) have big tech lock-in conspiracy theories about passkeys, and the conspiracy theories would be even more prevalent without a wide spectrum of consumer choice for credential managers.

>If you are using it with security in mind then my recommendation would be to use a hardware backed security key with NFC enabled. Everything else is pretty much lipstick on pig, they are worse than passwords in some sense from usage perspective.

Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation.

The only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential. But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session.

And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/

I would love for this feature to actually work but every time I've needed it to it hasn't. Literally this week I only had a passkey on my phone, but at the time I was in Linux with Firefox, and afaict the qr code workflow basically requires either chrome or windows 10.

If you don't want to downgrade security, how about requiring confirmation from another session that is already logged in using a passkey? e.g. You try to log in on PC2. A prompt appears with something like "confirm this login from [PC1, etc.]". You log in on PC1 using your passkey. The service recognizes that the login id definitely you, or at least someone in possession of your physical device and login method for that device. Therefore, it then allows PC2 to register a new passkey. Kinda similar to how google confirms new logins by sending a notification to your phone.

Also yubikeys have limited passkey slots (100, 25 with old firmware)

now multiply it with every web site you want to access.

(...and I’m pretty sure plugging my yubikey into a locked down public terminal is not going to solve this, either.)

Errr, no.

You can transfer a password from one manager to another. Those very same password managers won't let you transfer a passkey they hold.

And if you know the password, you can use it anywhere by just typing it in - no complex technology or protocols involved. But using a passkey involves your secure computer talking to another computer, using a complex protocol that can't go via eyeballs and fingers. If you don't have a way to connect the device holding the passkey to the computer wanting your id - say your USB A Yubikey isn't recognised by your phone, then you are out of luck - you can't use that passkey, even though it's sitting in your hand.

And you can't work around that by copying the passkey to a device that can communicate with the service you're using, because you aren't allowed to copy.

It's an unworkable mess. The mess is not created by passkeys themselves, because, as others have said elsewhere the protocol is pure elegance. The mess is created by vendors choosing lock in over transportability. I'm hoping it's a passing phase.

But this went out of the window when some genius decided that usernames were too complicated, so Passkeys had to be discoverable, which means they have to be fully stored token-side. Which of course has the nice side benefit of essentially killing hardware tokens and forcing people into using their Android/iOS/Windows device for it.

But the original FIDO2 standard wasn't made with consumers in mind in the first place, it was driven by enterprises that wanted high-assurance security. It works in that environment because, well, a big IT department controls it, can support the employees, and you can mandate and control its use.

It was just sort of haphazardly shoehorned onto general users/consumers, prematurely IMO, via synced credentials as a compromise instead of coming up with something better.

Passkeys came together with multi-device syncing when Apple introduced them and IIRC it was pushed as their killer feature by Apple back then, but passkeys can also be completely device-bound. The marketing around this was all quite confusing, but it's a bit too late to fix now.

What we got, as far as the average consumer should be concerned, is that "passkey" is any authentication mechanism (not the actual credential) that can replace a password. And it's still confusing.

Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors.

Also they decided they should be cloud-synchronised, so the something-you-have second factor doesn't impose the burdensome requirement for you to have something, which was apparently a big usability problem.

In the UK at least, there are very few brick & mortar branches anymore - banks expect everything to be done online.

Edit:

Oh yeah, I can also share SSH keys with friends and co-workers. I can freely choose which SSH key to use when authenticating and I can have an arbitrary number of SSH keys for a given server on each machine. Some of this stuff is esoteric, but some is not. Most of the stuff I can do with SSH keys I can also do with passwords but not with passkeys (or at least not always). Finally, as many others have mentioned, the attestation stuff is really ugly and takes control away from the user entirely.

[1] To be more accurate, although it was always proprietary, 1Password was also local-only at first, with syncing only supported by putting it on something like Dropbox. They only added native cloud syncing later and eventually made it cloud-first.

Both passkeys are independent of each other and know nothing about each other, only the website knows that both are mapped to the same account.

It's like setting up multiple API keys for a service. Passwords are usually restricted to just one, but passkeys are (generally) allowed to have multiple backups.

When I go to login to Google, for example, it will prompt for a passkey. Currently, in Safari, it will prompt for biometrics on my iCloud passkey. I can either give it my fingerprint/face, or hit the "More options" button, which in the current list allows either 1) insertion of a USB security key, or 2) presenting a QR code that a phone device can scan, allowing use of the passkeys on the phone.

(All very good questions, BTW!)

Just absurd.

The biggest point of confusion in my opinion comes from Windows especially having lacked a way (and kind of still does) to save the private key of a passkey to your password manager, defaulting to saving it to Windows Hello, which saves the private key to your PC's TPM. In this scenario you can no longer easily copy the private key to other devices, and if you lose that Windows PC, you also lose the private key and the whole passkey as a result.

This is my issue with passkeys. Either we lessen security to improve UX (syncing across devices implies extracting private keys from secure enclaves, at which point it’s no different to password syncing), or we have a proliferation of different keys per website across devices (assuming the website supports multiple passkeys).

Perhaps this trade off is not resolvable in a way that happily satisfies both the security constraint and the UX requirement.

Or google. If you use android and chrome then it all just works.

But god help you if you want to use a password manager to keep everything in sync; I haven't yet found a way for a mobile app or web page to explicitly signal to the device that the passkey to be created should live in $password_manager and not whatever built-in/on-device key-store exists.

So I only really use pass keys for desktop/web things because that's the only place the "store/read from $password_manager" flow _works_.

Maybe... I just ran into an annoying scenario where the largest bank in Canada made an administrative error where they mislinked an account belonging to me to my wife's profile.

I went to a physical branch to get it fixed and was told that branches don't have that kind of ability so I'd have to call customer support.

I called customer support and failed the verification questions because the expected answers were wrong, based on their own clerical error. After failing the verification questions, I just got a "we have to end this call, no additional information can be provided, please visit a branch."

I was able to get around it by calling back in and providing the incorrect, but expected answers to pass the verification step - I imagine, however, that this could have turned into a real nightmare for seniors, or anyone who wasn't able to deduce what the expected verification answers were.

Basing your security decisions on "it'll never happen to me" because there are billions of other users who will get burnt first is not a wise strategy either.

Why take the chance when there are so many other alternatives that let you own your vault or at least companies that still have some semblance of a support team.

Losing a decade of my Google Maps Timeline data even with backups enabled made me realise I may not be lucky enough to win the lottery but I am lucky enough for Google to pick little old me, hidden in the billions, to lose my data.

As to

> No major bank revokes your password when you setup a passkey, either.

If we're talking about requiring 2FA via TOTP or challenge-response hardware tokens or banking apps implementing such, that depends on the country. It's the status-quo in some places. Some banks even put the input field for the token output as a third input in the login form on their website because all customers have them. The rest separate their login form in multiple steps, but they likely require it of all customers too.

No argument from me there, just stating what the design actually calls for.

It was never meant to be consumer friendly in the first place, it's an enterprise standard. It was just shoehorned onto consumers with the synced credential compromise to make it easier, instead of coming up with something better, and then just calling it a "Passkey" which now has dual meaning.

But the real solve is difficult. If a system requires a consumer user to manage, remember, or safely store something extra, it will fail.

If you’re not storing the actual private key in the Secure Enclave but only the “access to it” what’s changed from how Apple’s keychain already manages password syncing to iCloud?

The only benefit (and it’s still a decent one) is that some random website breach can’t disclose your private key.

so. no clear explanation.

To be fair, trusting users with passwords/credentials is how we got into the mess of phishing et al in the first place.

The bad news is this could change.

I use multiple devices and I want to log in to things using only my master password. I also want to be able to back up my credentials to local encrypted storage so I can restore them if my password manager service provider stops operating or becomes untenable.

Until we find a way to securely implant a Yubikey in people's brains, it isn't going to happen.

The OSes I use where that works fine:

- Android - Windows - Linux - macOS - iOS

With the "cloud password manager" angle there is some hope of being user friendly, although we're certainly not there yet for most folks.

KeepassXC was threatened to be blocked.[1]

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

1. This can be subjective, Unfortunately Customer identity is not on the highest priority from security perspective, its all about ease of product use when it comes to customer identity. For customer identity, most account recovery methods still fall back to email or SMS even if you have 2FA configured. The real money lost with phishing is with enterprise identity, when some one poses as an employee. The recovery of these accounts can be managed. If a customer account gets hacked then the business is not really on the hook to make it even.

> Usability of passwords

This is the biggest point of contention as per my interpretation. The industry did a very poor job of securing their infrastructure leading the massive leaks of password databases. Instead of fixing that goal post changed, with the by introduction of PASSWORDLESS. The passwordless works just fine for enterprise identities, not the customer identity. Even for enterprises, you cannot get rid of passwords if you get into AAL concepts (guidelines provided by NIST for authenticator assurance levels)

4. I was working on WebAuthn when the term passkey was not there, I was there when the term was introduced, I saw how every one was trying to map their existing definition/understnading with the new terminology specially the part where Apple just announced them to be syncable. Enterprise companies had to actually disable the Apple Passkeys for this reason to begin with. I found it interesting to see how Yubico changed their documentation overnight, they switched every instance of WebAuthn keyword with Passkey. It took some time to settle on how to categorize discoverable credentials (where meta information about user is on the device in addition to credential) and non-discoverable credentials (hardware keys, they are limited in space so they did not store user meta information in earlier versions). Eventually google took the lead in calling the credential where private key cannot be synched as Security key and everything else as Passkey. Resident key, syncable, synched are all different bits of the WebAuthn assertion

5. Thats an interpretation of how I read things based on the overall play going on.

> Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation.

The security aspect is tightly coupled with the authenticator implementation. The phishing aspect is the only default good in here, it just means that the credential is strictly tied to a particular domain, the one on which it was set, that too is highly dependent on the client (browser) doing the right thing. Additionally you have to count on the server to not get compromised as well (There is a a feature to support multiple domains).

Most importantly, when you make something this hard and complex to understand then be advised that people are going to make mistakes in implementation and leave gaps in security.

Now, if only Windows, macOS, and Linux can get together and fix whatever needs fixing to get headsets to connect properly automatically, that'd be grand.

Also, remember when one of the maintainers of the passkey standard warned that KeePassXC users would get blocked by relying parties [0]? Would you allow tech companies to determine what password manager you are allowed to use?

0: https://news.ycombinator.com/item?id=39698502

- Only one specific device can ever login (bad).

- It doesn't limit login to one specific device, therefore it does nothing.

Linking Passkeys to a physical device was always DoA. At least not without a way to enroll every device you own, and strong recovery strategies. But considering how inconsistent every company's Passkey implementation is (inc. many that only allow ONE TOTAL!), it is DoA.

BitWarden, KeePassXC, and probably a bunch of other password managers have very thorough support for import-export, automatic/periodic backup, sync/merge, etc.

passkeys are not meant to be a second factor; they are meant to replace the password as a primary factor.

>to protect against the theft or compromise of your primary device.

I love Yubikeys, but the only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential.

But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session.

And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/

I have no idea if Yubico is involved with DBSC, but I would hope that they are, because it would help them make Yubikeys live up to the security guarantees that I personally feel are heavily implied by their marketing.

Which entirely defeats the point of using passkeys. There shouldn't be a passkey provider the "provider" is your device's TPM/secure enclave + your biometric challenge. They are supposed to be mathematically non-exportable, device-bound.

Arguably, that's the only way forward. SSI is also nice because you get to fully control what you share and don't share (e.g., age verification, you get to only share "I am over 21" and no other information).

Passkeys were (are?) supposed to be just a password replacement though. That services are using them to replace a username AND a password AND 2FA is a problem that's turning the device into your identity, instead of keeping the identity as three parts (What you know, what you have, who you are (biometrics)). Now we've just turned the "something you have" into the entire identity stack.

in poland we have similar to passkey implementation for government profile, that is then used to login to most/all government websites or to sign government documents. you point the camera on the qrcode, confirm it on the phone and you are done. this same app has your ID, which can be used in most places (shops, banks, police etc).

and btw im using linux (main box), macos, android and ios - no issues so far with really cross device usage

There's a strange tension where I want to use pass keys because they are easy to use but also they are easy to lose, so I choose a KeePass synced over cloud and deal with a bit of a hassle by having to copy/paste my passwords.

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

Also it could be vulnerable to MFA fatigue attack, if people would constantly get new "confirm this login" popups, they would press anything to make it go away.

So you would need something that is explicitly initialized from a trusted session, then you need something to connect the trusted session to the new login. If you want that to be user friendly you need some short codes and can't rely on QR code / Bluetooth, or two-way interaction. And that brings up the phishing / MitM attacks again.

In fact, if you have your Apple Passwords app set to sync through iCloud, you can:

- Make a passkey on your Mac for a site in the Passwords app

- Go to a different computer (a friend's or whatever)

- Attempt to log in, choose use another device, it'll show the QR code

- Use your iPhone to scan that QR code and sign in, as the iPhone has the passkey synced through iCloud

Note, the same kind of thing is also possible with other password managers as well.

Stranding private keys in clone resistant secure enclaves has unacceptably bad UX for the average user, which is why very few implementations try to do that.

So yeah, this is cross platform on iOS, macOS, Windows, and Linux.

You still get the phishing resistance, though!

You scan the QR code, click the confirmation button, and you're signed in. It's part of the standard UI of normal operating systems.

Might not work (well) if you're on an old computer without decent Bluetooth but everything has Bluetooth these days.

But I'm also a person who generally never experiences the issues some people have with Bluetooth in general. If I ever have an issue with Bluetooth on a computer, I swap out the wireless chipset with an actually good one. Its almost always just bad hardware. I've only had to do that a few times in the last decade though, more modern WiFi/BT chipsets are generally pretty OK. Its the old ones that are near worthless.

Although I will say most of the time I just plug in my USB authenticator. I normally only fall back to the QR code if I don't have my keys on me.

And as an edit, I wasn't aware fully that the QR code is to help assist the BT handshake, I had assumed it was posting a signed request back to the service. My bad, my above comment isn't completely correct. Thanks for cluing me in to the BT requirement for the QR code path.

How can I do that, if Passkeys are the only option to log in?

If I can just use a password to log into a website without Passkeys, then Passkey is useless and doesn't add any security benefit.

> Why would you need to delete invalid passkeys? You wouldn't.

I sell my old (and no longer updated) phone or PC and don't want someone to get access to my account by getting access to the secret keys.

An non-revocable authentication mechanism is just stupid.

What are the branches even for if not customer support?

You can click "try another way" and use your password, and then you'll have access to your bank. But then, you should try to resolve that problem. If you (or a trusted friend/family member) can figure out how to use settings to remove the passkey from your bank's account settings, you can do that, or you can ask a bank teller to help you, instead.

(And, luckily, you won't need a bank teller, because you'll still have access to your account.)

Your master password to your cloud PW manager's vault is also phishable (hence why passkeys were ideally device specific, non-exportable).

Its phishing resistant not phishing proof

On Android 17 (on Pixel) you can select the password service under Settings -> Passwords and passkeys -> Preferred service.

If you have an alternative password manager installed, it will be listed there along with Google's own password manager. iOS has a similar setting but I don't know exactly where off the top of my head.

That's not my argument. My argument is that your evidence that Google is uniquely bad at locking people out of their accounts is not good evidence. A few stories in the news represents a beyond negligible fraction of billions of user accounts.

Those are absolutely not passkeys. Passkeys are just WebAuthn (from what i can tell).

1. PayPal was looking for a physical authentication solution for their users, Michael Barrett was their CISO at that point and he became the president of FIDO.

2. Google developed Gnubby (which was internal, and therefore enterprise) and they wanted to push a similar authentication to their end-users, supported directly on Chrome. They wanted this to become a standards, so donated the underpinnings of the Gnubby technology which became FIDO U2F.

I might be wrong but at least these are the two parts I know.

And while the original FIDO could be called dual-use, Webauthn and especially Passkeys were developed to be first and foremost a customer-facing standard.

It doesn't mean they are not confusing, but they are clearly designed with end users in mind.

https://bitwarden.com/resources/passkeys-are-phishing-resist...

As a consumer, I don't give a shit. I use my driver's license to apply to jobs, my passport to fly, and a password (with 2FA depending on how much I / my employer cares) for everything else. I prefer whatever I use for 2FA to not be device-bound, because that's obnoxious, error-prone and constraining.

As a consumer, I don't see any reason for my auth to be more complicated than that.

FIDO 1.0 started as two different standards: UAF and U2F. U2F was for USB keys used as second factors (so almost always stored in a TPM-like chip and device-bound, but not provided by your platform and there could be multiple of them). UAF were either provided by your platform or by any software and there was no requirement for them to be stored in TPM. Back in the day, very few platform had any FIDO support built-in, so in practice UAF was always done in software (usually based on whatever biometrics/TPM the hardware provided).

So competing options were the default for early FIDO, getting a default platform option is something that came later.

The baking in "which authenticator is storing this passkey" and "require user to provide biometrics/pin to verify presence for this passkey" and "don't make it easy or possible to export passkeys" behaviour is more just control.

I guess it sort of helps if the threat model is complete remote code execution inside the victims brain because you got them to export their keys to you, but it seems more useful for websites and governments whitelisting what hardware and software they deem acceptable.

That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys"

> It doesn't limit login to one specific device, therefore it does nothing.

It's not nothing. It provides an attestation that you the user are in physical possession of the device, and have passed the challenge to release the key form the TPM (biometrics, pin, something like a yubikey).

Giving your private key to a cloud password vault makes it phishable again (via an attacker getting acsess to your vault, just like with passwords). The private keys are supposed to be non-exportable, and the cloud password managers defeat that as well.

Isn't this true of any authentication method? It doesn't seem unique to Passkeys.

Which would make the whole scheme unworkable (at least for me).

Which I’m sure is great in theory. But IMO just adds even more complexity to a system that already has several moving parts and is more fragile than it should be.

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

Here's the most readable reference to playing favorites on passkey vaults I could find from the FIDO Alliance (the previously mentioned 'cabal of evil').

See Section 2.2: "Validating FIDO UAF authenticator attestations against the configured authenticator metadata to ensure only trusted authenticators are registered for use. "

And Section 2.3: "Verify attestation assertions made by the FIDO UAF Authenticators to ensure the authenticator is authentic and trusted. Verification occurs using the attestation public key certificates distributed via authenticator metadata. "

https://fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fid...

Basically, Relying Parties (the sites you are logging in to) are expected to allow/disallow certain passkey authenticators (the devices or software that hold your passkeys), based on registration and trusted lists. The FIDO Alliance can use entry into those trusted lists as a cudgel to force compliance with the standard. Effectively, the standard is that users must be locked into to proprietary ecosystems, unable to escape.

It is not feasible to remove password login or some other recovery login method.

> If I can just use a password to log into a website without Passkeys, then Passkey is useless and doesn't add any security benefit.

It isn’t useless, point is you don’t get to type in your password on a device that has passkey generated already, or get phished on a fake web address for example.

> I sell my old (and no longer updated) phone or PC and don't want someone to get access to my account by getting access to the secret keys.

Passkeys are meant to be protected by either PIN or biometrics, however they are also meant to be revocable on the web, at least they are for services i’ve been using with passkeys.

You forgot about the endless frustration and annoyance.

> Your master password to your cloud PW manager's vault is also phishable

... which is why all sensible cloud vaults have a separate enrollment key, requiring an explicit action to grant a new device access.

https://support.google.com/accounts/threads?thread_filter=(c...

How many times do you have to click "View more" to reach a post from last week? It's a problem.

The copy pasta advice from the "diamond product experts" says it all:

Account recovery is completely "self service". Google doesn't provide any form of live support for account recovery. If you can't recover your account using Google's automated recovery process, the account is lost. [1]

[1]: https://support.google.com/accounts/thread/453660883/locked-...

Not true. The original concept was always for them to be cloud synced.

This has nothing to do with their anti-phishing capabilities. The anti-phishing capabilities come from the fact that the password manager authenticates the application before handing out the passkey. It doesn’t matter if they are synced across devices or not.

You are correct that other login methods might be weaker than passkeys. I’m not sure how that’s related to passkeys though. In real security sensitive applications the recovery process is “go to the bank’s branch and show them your driver’s license”.

> Your master password to your cloud PW manager's vault is also phishable

No, it’s not. You would need to steal my yubikey to get access.

In the US, only about 34 to 36% of adults use a password manager. Of the ~64% that don't, an alarming 20% reuse the same password across almost every service, and a ton just rely on browser autofill.

If you use a password manager, you are in the minority. Hell, even if you don't use a PW manager and you at least use a different password for different services, you are ahead of most people.

The general population is largely computer illiterate, and have a staggering lack of basic security hygiene.

I'm yet to see a site that doesn't provide a password reset (excluding websites without passwords). What inane webdev though that'd be a good idea?

Reminder that Facebook has warnings and prevention mechanisms to avoid users pasting malicious JavaScript into the console on Facebook.com (which would exfiltrate session cookies).

Preventing users from accessing these keys directly makes sense!

In fact WebAuthn is explicit that you should allow multiple tokens. But every time I see an HN thread it has people who insist this doesn't work or at least isn't common. When asked for examples, if they give any answers...

1. Most often these are sites where you can't use this technology at all. They'll have TOTP or something and apparently "I don't know anything about this" == "I know everything there is to know about this topic" in the increasingly LLM-crazy world we inhabit.

2. Usually otherwise it's AWS. Which is pretty annoying, but it's one site. I have like a couple of dozen places where I use WebAuthn and in all of those two (or three, or in a few cases four) tokens are enrolled. I don't have an AWS account, my employer is a Microsoft-only shop in this respect.

Too bad for Yubikey. I don't need them any more.

> That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys"

Unfortunately, given the laziness, incompetence, and cost-consciousness of organizations like traditional financial institutions, telcos, governments, etc., many of them have & will end up with that implementation.

At virtually all banks, the bank tellers cannot help you with login problems. You will have to call the bank's tech support and somehow navigate AI-modulated phone menu hell.

I have this set to my password manager but I still can't _use_ the pass-keys in my password manager to sign in to most apps.

Lots of physical locations make the bank seem big/safe/reputable.

Beyond that, it's sales and a place to have ATMs. I have sometimes been able to get a replacement card issued at a branch instead of waiting for one to show up in the mail.

Some branches will accommodate special requests like "can I withdraw $200... in two dollar bills" / take coin deposits but that's been increasingly rare.

Kind of feels like "crypto is a type of currency and not all cryptography", or "SQL Server is a specific product of Microsoft".

Wonder if how it happened this time was people read the specs and explanations of WebAuthn, saw "passkey", never seen that word before and assumed it's only ever been used in the super narrow context of WebAuthn so it can only mean that. Maybe "header" can only ever mean "HTTP header".

Thinking about it like that, it may be more like how "latte" is specifically espresso with milk (it's really just milk), or "queso" is specifically cheese dip (it's really just cheese of any kind), or "masa" is specifically made of corn (it's really just dough of any kind, or it's mass like atomic mass is masa atómica).

Then passkeys doesn't provide any real value if you have other less secure recovery option.

Let's say I have a bank account, going to the branch and doing an in person ID check is a valid recovery option, but nobody would want to do that just to log in from a new device.

> It isn’t useless, point is you don’t get to type in your password on a device that has passkey generated already, or get phished on a fake web address for example.

That's solved by letting the browser to remember the passwords.

> Passkeys are meant to be protected by either PIN or biometrics, however they are also meant to be revocable on the web, at least they are for services i’ve been using with passkeys.

PIN and biometrics doesn't have any inherent security. They rely on some hardware (or software separated from main system) feature, and even those can have vulnerabilities.

Setting your preferred password/passkey manager on Android 17 to 1Password works fine in Chrome and Firefox to log in to any site, presenting passkeys managed in 1Password. It also works in all of Meta's native apps. (I'm pretty sure it works the same in Bitwarden.)

Whatever issue you're having, it's not an inherent limitation of Android passkeys. It might be a bug in your passkey manager…?

Yubikey tried to solve this, for obvious reasons. Their proposal was DOA.

Once 1Password supports proper single export when I make a new passkey I'll store it there and later export it to Apple.

Meanwhile I simply make two passkeys. I've only run into I think two sites that supported passkeys but would not let me make two.

On most sites making a second passkey is as simply as going to your security settings, finding the passkey settings there, hitting the "add another passkey" link, and pointing your phone at the QR code it shows, and then on those phone choosing the password manager that you did not use for the first passkey.

https://support.google.com/chrome/answer/13068232?hl=en&co=G...

https://1password.com/blog/import-autofill-organize-whats-ne...

In security, you identify reasonable threats. You can't protect against all of them, and some may even be contradictory.

When I get a call on my phone that says "Potential Spam", I have never even once in my life decided to run over to my list of passwords and hand them over to the President of the Spanish National Lottery. Not even once.

But on many, many occasions I have dealt with a simple system that was replaced by a more complicated one and something in that Rube Goldberg machine broke down and deprived me of access to money, email, even a parking permit to my office.

Passkeys seem to protect against the former case that has never happened to me, while increasing the chances of the latter that has happened way too often.

I don't have a citation for you just recent experience, do you have a citation?

My credit union has people who can help with any online banking/website login issues. They aren't tellers, but they are there. You just need to ask to speak to a customer service rep.