[thought_alarm]

The inability to move them is a feature, not a bug. If you can't move them you can't accidentally give them to the wrong person.

A passkey only authenticates a device (or group of devices). All passkey providers must provide secondary methods for validating the identity of their users so that additional passkeys can be issued when a device is lost.

But if that secondary validation is garbage then the passkey is also garbage, but that problem is not unique to passkeys. (Strong passwords have the same problem, they're only as strong as the reset mechanism).

[koito17]

> The inability to move them is a feature, not a bug.

Wasn't the whole point of passkeys over FIDO2 keys the fact that you can have the same secrets stored on more than one device? (thus mitigating the largest pitfall of FIDO2 keys -- losing the physical key)

[TheNewsIsHere]

Passkeys are an implementation of FIDO2 - technically an expansion of the protocol to include so-called platform authenticators that are device bound, but also syncable credentials, which is what the major players are implementing with storage in iCloud Keychain, Google Accounts, Microsoft Accounts, password managers, etc.

In this way the promise of passkeys, and the main marketing message around passkeys, is that they are phishing-resistant. This isn't strictly true though, because within some of these syncable ecosystems you can share a passkey. For example I can AirDrop a Cloudflare passkey to someone else's iPhone. If they accept, they can now authenticate as me.

The core intentions of FIDO2 generally and passkeys specifically is sound, but solving the age-old problems of device loss, resets, impersonation, sharing, etc, are human issues that the tech companies and consortiums still can't solve. In this way I would argue that passkeys are an improvement but are oversold. They are still better than passwords for many use cases though. And IMHO should remain optional.

[romwell]

>In this way the promise of passkeys, and the main marketing message around passkeys, is that they are phishing-resistant. This isn't strictly true though

So, it is not true.

However, what's true is that if you're arrested, the police won't have to ask Google/Apple/anyone to give them access to your accounts.

They'll just hold the phone to your face, and get a convenient list of all your accounts and a means to log into them.

Granted, you'd need to have biometrics involved. But you can be simply asked to unlock the phone, if that's FSB doing the asking, you won't say "no".

[TheNewsIsHere]

> However, what's true is that if you're arrested, the police won't have to ask Google/Apple/anyone to give them access to your accounts.

> They'll just hold the phone to your face, and get a convenient list of all your accounts and a means to log into them.

As with any password manager installed on your phone. Passkeys don’t claim to solve and are not intended to solve that particular kind of threat.

[oidar]

They are designed to be exportable - the clients just have have not exposed an implementation of that. https://news.ycombinator.com/item?id=35855133

[hedora]

Here's a great github discussion about passkey plaintext exports.

Apparently, the FIDO alliance is considering adding an attestation feature that would allow websites to block various passkey implementations:

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

e.g., they could block ones that allow exports, or they could block ones that are FOSS. To their credit, it looks like Apple's throwing their weight around to prevent such blocking from being technically possible.

The more I hear about this standard, the more concerned I become.

[TheNewsIsHere]

I expect Apple's focus on privacy (whether you wish to believe that is for marketing, or real) is at play here. While passkeys don't really work as a tracking mechanism, you could do some profiling based on attestation. I am sure Google would love for you to use passkeys and be able to control what devices those are used on, and know about what devices you have. "Oh you want to sign into YouTube? Are you really on an iPhone, or are you pretending it's an iPhone?"

I use AAGUID attestation for Yubikeys at work, but that addresses an actual security need to enforce known authenticator types and prevent enrollment of non-hardware tokens.

[whatevaa]

Losing access to a service because of device loss is part of threat model for most people (including me). Security isn't binary. Failure to provide adequate recovery should be treated as insecurity.

Always do threat modeling when talking about security, otherwise you end up just bike shedding.

No joke, I once recovered access to google account by loading a TOTP backup in an app in Android emulator. Otherwise I might have been a bit in trouble.

[whartung]

When I bought a new iPhone, and restored it from my old phones backup, my TOTP data from the Google Authenticator apparently didn’t make the trip.

If I didn’t have my GitHub recovery codes, I would have been in trouble.

Arguably, that’s what those are for. But the key point is that I did a mundane, routine transaction. My house didn’t catch fire, my phone wasn’t stolen, I didn’t act negligently. But I was potentially this ][ close to disaster.

[hedora]

Computer security is usually defined as achieving three things: Confidentiality, Integrity and Availability.

If device loss (or a google/apple account ban) leads to permanent loss of access to your (other) accounts, then passkeys aren't providing availability, so they're not secure.

Put another way: If you ignore availability, then passwords are even more secure than passkeys when used "correctly":

When creating a new account, choose a random 80 digit string for your password and don't record it anywhere. Also, don't set up an account recovery email address / phone number / etc.

[hombre_fatal]

Of course, you're always at the mercy of customer service. Not having a backup email or phone number can make your account easier to attack since the customer service agent has fewer options before they resort to just giving your account away to the attacker.

[tomjen3]

Hard disagree on that being a feature. It’s why I don’t want to use them.

[thought_alarm]

From the perspective of the security experts who designed the system, it's a feature and a requirement.

[ndriscoll]

And those experts have designed something entirely inappropriate for non-corporate users (who can't just have IT reset their credentials) largely solving problems no one has while introducing real problems (e.g. accidental self-DOS and backdooring device attestation into the web again).

Browser generated strong passwords with auto fill exists today, pretty much solves all security concerns, and doesn't have the same pitfalls.

[aledalgrande]

Security that is too hard and inconvenient to use is not security any more, because users are going to get around it.

[romwell]

>From the perspective of the security experts who designed the system, it's a feature and a requirement.

Great, all day I dream of making someone else's job easier by adding hassles to my life.

What's next from the "security experts", booby-trapping front door entrances to deter thieves?

Oh, I have another idea. Let's restrict the number of accounts people can have to, like, two, so that they don't have to struggle with remembering passwords! From the perspective of IT helpdesk, it's a feature and a requirement.

[tomjen3]

Their perspective is not relevant for me.

[romwell]

>The inability to move them is a feature, not a bug. If you can't move them you can't accidentally give them to the wrong person.

Have you considered the case of "the wrong person" taking the device from you non-accidentally?

I'm glad that you live in a world where you've never had anything stolen (..or confiscated by officials).

What a wonderful feature: give anyone who can snatch/break my phone an easy way to lock me out of all my accounts. Especially useful when traveling.

Not to mention the absolutely-never-happening scenarios like, um, dropping the phone. Should've backed up you keys!

(Apple will gladly restore them for you from the cloud once you purchase a new iPhone)

Oh wait, never mind: "The inability to move them is a feature, not a bug."

>All passkey providers must provide secondary methods for validating the identity of their users

Like what, getting an OTP on a known device / phone number / email that you no longer have access to?

Who's enforcing that must?

And finally, and please think about it for a moment:

If another means to verify identity MUST be provided, passkeys are not REPLACING anything - so why do we need them?