[oidar]

I'm hesitant about embracing passkeys. I think passkeys are poorly implemented at this point because of the inability to move them around like passwords - I don't want to be locked in. But I don't think what he is explaining is forcing an automatic upgrade for passwords, he is explaining that it can happen at the request of the user or application prompt. Notice that the diagram - The user in the app requests to upgrade (sure, let's call it an upgrade) from a password to a passkey.

[bigiain]

Same. I have a pair of Yubikeys that I have a quite strict process of management that I'm confident enough in. One lives in a "fireproof" lockbox, the other on my keyring - and I make decisions about whether to get the locked one out when activating 2FA immediately or wait til later based on the nature of the login I';m protecting. I will keep using this as long as needed until time and social media outrage (or lack of) proves out the effectiveness of passkeys over time.

A second Yubikey in a safe is a lower cost option than a second passkey compatible device...

[HeatrayEnjoyer]

What happens if both are lost? Homeless people often lose/are robbed of their possessions. Many people have abusive partners. Sudden destructive emergencies occur (house fire, night tornadoes, unfortunate simultaneous emergencies).

What is the recovery process and what prevents it from being gamed itself?

[bigiain]

Sure, that's a risk.

But I bet those scenarios you've posited apply equally to the devices with your passkeys on em, right? I'm confident enough that between the one on my keyring in my pocket and the one in my lockbox at home, if I've somehow lost access to _both_ of those I've got more problems in my life than my gmail/github/whatever logins.

And the recovery process and gaming thereof questions apply equally to the passkey protected accounts as well, no?

[romwell]

Yes, the question is: what's a person to do in that case?

Particularly if they only have one device (a phone), and they lose it.

[HeatrayEnjoyer]

You rephrased my question, but didn't answer it.

[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?

[stpn]

It doesn't seem like it will i.e. _delete_ your username/password, but the behavior is actually automatic without user prompt.

See 1:10-ish[0] for the demo - I found this at least somewhat surprising, though I submit this as a passkey advocate (for a while, my side business only-supported passkeys, but we backed away from that).

[0]: https://developer.apple.com/videos/play/wwdc2024/10125/?time...

[faeriechangling]

I'm using exportable passkeys in .kdbx format right now. There's no reason conceptually why passkeys have to be non-exportable. Regular keys are only seldom implemented in that way.

[JakaJancar]

The lack of export scares me too, but is it really a problem?

If I were to switch to Linux, I guess it just means that I'd have to go through the forgotten pass(key) flow on every site on first login?

[bigiain]

Yeah. For a while when I was mostly working on mobile apps, I'd switch between iOS and Android every year. I've almost like clockwork switched between macOS and Windows with every job change. I'm very much leaning into going all Linux for personal stuff based on MS and Apple's pushing Gen AI into the OS.

I'll stick to Yubikeys and TOTP 2FA for as long as I can instead of jumping into passkeys.

[DeepYogurt]

This is largely mitigated so long as services allow for more than one passkey