[figbert]

The argument that passwords are acceptable as long as everyone practices good "hygiene" strikes me as having many parallels with the argument that C code is memory safe as long as it is written properly.

I'd rather just have memory safety built in to the language I'm using—I'm not sure exactly what the equivalent is for passwords, but I don't think I would oppose it.

[creshal]

> I'd rather just have memory safety built in to the language I'm using—I'm not sure exactly what the equivalent is for passwords, but I don't think I would oppose it.

It's a hard problem. I don't think passkeys really are the solution long term, they just sweep the problem under a corporate rug and ignore that people will still use them inappropriately.

[rjzzleep]

Not really, to some extent some amount of collateral damage is necessary for a free and open society. I don't want to live in a nanny state that decides everything for me.

But somehow the same people arguing for ultimate freedom and OSS are also arguing for centralization of passwords into corporate controlled infrastructure.

I'm somewhat at a loss on how to argue on these issues. You want to hand over control over your key infrastructure to big tech and you want the average population to do that as well? Go ahead. Most people on iPhones already use sign in with Apple with apples 2FA system anyway it won't matter to them.

But why encroach on me and force me to use it to protect me from myself?

[5e92cb50239222b]

You can always use a FIDO2.1 key as a passkey, they're not tied to the big tech. I don't even have a smartphone and have been using them on the couple of sites that support passkeys just fine.

We will also have at least one open software implementation when this gets merged:

https://github.com/keepassxreboot/keepassxc/pull/8825

There are braindead implementations like PayPal's:

https://www.paypal.com/us/cshelp/article/what-are-paypal-pas...

that force you to use Android or iOS, but it's nothing new, they manage to fuck up everything they touch (for example, U2F 2FA only supports registering one hardware key and it has been that way for years).

[madeofpalk]

What part of Passkeys is "centralization of passwords into corporate controlled infrastructure"?

"Big Tech" does not control Passkeys beyond the work on the underlying WebAuthn spec https://www.w3.org/TR/webauthn-2/, and that they develop implementations of that spec.

[ValleZ]

Because users who lost account because of lack of 2FA usually require attention and support resources. It’s easier to require more security than to figure out if this is a legitimate user who is trying to get access.

[cassianoleal]

> they just sweep the problem under a corporate rug and ignore that people will still use them inappropriately.

Can you expand on these 2 points? I'm still trying to wrap my head around passkeys and these are some of the arguments I see around but never quite explained.

[michaelt]

From a certain perspective, passkeys are a lot like using "Sign in with Google/Apple/Microsoft account"

Because if this passkey stuff takes off with normal people, 98% of passkeys will be stored in cloud accounts with those providers.

The weakest link in the security chain is the procedure for when the user forgets their password / loses their phone / gets a rootkit / gets phished / has their e-mail compromised. You can transfer that problem from your site to a cloud provider and hope they do a good job - but the problem doesn't go away.

[cassianoleal]

> 98% of passkeys will be stored in cloud accounts with those providers.

They will also (and primarily) be stored in the individual devices, and don't need cloud access to the providers in order to be used.

In this sense, it solves one of the main issues with third-party sign-in, i.e. that if the provider decides to lock your account, you get locked out of any linked services.

> You can transfer that problem from your site to a cloud provider

With passkeys? How so? Are passkeys not just cryptographic key pairs? If your service associates a certain account to a certain public key, there's nothing an external cloud provider can do to solve the issue you describe.

It's possible I've missed something, like I said before I'm still wrapping my head around the whole thing.

[michaelt]

> If your service associates a certain account to a certain public key, there's nothing an external cloud provider can do to solve the issue you describe.

Without passkeys, if one of my users lost their "second factor" (e.g. lost phone) I had to provide a flow for them to get into their account despite that, while remaining secure.

With passkeys, users can restore their "second factor" from a cloud backup, so long as they can get access to that cloud backup. Hence, my lost-second-factor flow is outsourced to the user's cloud provider.

[pcthrowaway]

If your passkey is issued by Google on your Android device, and Google decides to revoke your account for violating some arcane term of service, how long until you lose access to services with those passkeys? At the very least, I imagine you lose it if you get a new device?