[SadWebDeveloper]

This looks and feels like passwords with extra steps...

I mean now i need to "store, manage and secure" my per-user-certificate sorry "my passkey" myself and if its get compromised its my fault, how are passkeys more "secure" than enforcing a secure long password that the user can't change unless he met certain conditions and its conveniently stored inside the password manager i just built.

What happens if i lost all my devices due to a fire? at least a password let me still access things we these i might need to prove again that i am me, it might even be more easy to steal accounts because i can ask google to change it because i lost my passkey.

[lxgr]

Passwords can be both stolen (they are valid for multiple authentications) and are susceptible to phishing/MITM attacks.

TOTP/HOTP solves the first problem by making the credential provided during authentications single-use, but they're still susceptible to phishing/MITMs (since you don't know where you're entering your OTP).

WebAuthN solves both.

> What happens if i lost all my devices due to a fire?

Passkeys are synchronized to your device ecosystem vendor by default (i.e. Google or Apple, and soon also third-party password maangers on Android), for better or worse.

[garganzol]

> Passkeys are synchronized to your device ecosystem ... and soon also third-party password maangers on Android

And at that point they make a full circle becoming just passwords with a master password. Essentially what password managers already do. You already can tie a master password to a biometric or another factor.

[lxgr]

Not quite: Passwords are long-lived bearer tokens, which can be phished/MITMed (exclusively using auto-fill helps, but non-technical users are still prone to be phished) and are administratively harder to securely manage on the backend of the relying party.

[JohnFen]

> Passkeys are synchronized to your device ecosystem vendor by default (i.e. Google or Apple, and soon also third-party password maangers on Android)

That's a showstopper for me, personally. Not saying the idea is a bad one (at all!), but I won't be using it for myself.

[lxgr]

Me too – I'd much rather trust my password manager, so I'm hoping that platform/browser APIs will eventually become available that will allow such third-party implementations. (Android is planning to; iOS hasn't stated anything yet.)

Even then I would probably not add my bank credentials or other high-sensitivity things there.

[dcow]

The solution, for you, is a cloud synced passkey manager, possibly a custodial one.

A password manager with strong passwords is weaker than a password manager with passkeys, because passkeys use asymmetric crypto and passwords+2fa involve exchanging a shared secret over an insecure channel at some point (yes I'm considering 1-sided TLS an "insecure" channel here).

Trust the security experts when they say passkeys are more secure. Now, solving the UX to make it match that of passwords plus managers today is the problem, agree.

[SadWebDeveloper]

So in the event that i lost everything, i mean catastrophic, like my house burned to the ground with all my belongings, i have no kin nor "trust alternate people" configured for my account, my password manager requires my "synced in google/apple drive/cloud" passkey or my last known device, i can't retrieve it in anyway, how can i recover my account?

Either have to prove that m me to my account provider, which essentially is huge security hole since what data it will be required to prove might be more easy to fake (kinda like how people do sim swapping) and stole my passkey or do the "crypto thing", that if you lost your decryption key all your money is gone forever and ever and start fresh.

I mean my point is... password are not going to be deprecated, we had so many attempts to murder them but their convenience outmatch any other solutions, feels like passkey aren't well designed imho if the backup requires a password, then passwords won't be deprecated... maybe passkeys aren't meant to replace password but long-sessions oauth tokens if you ask me why passkeys exists.

[dcow]

Sure. The idea of authenticating a human based on something you know, passwords, is still useful and not going to die anytime soon. But it would be a much much safer world if you only had to remember one or two passwords than if you had to try and get passwords right for every service you use out there. A single password protecting a keychain full of passkeys is still better than reusing that same password on every single site. Hands down no argument. This is why passkeys exist. They are objectively a superior technology and you are objectively safer using them, as long as you can comfortably recover from disaster scenarios. The fact that you might choose to still use a password to get access to your passkeys is, well, up to you. You're free to take whatever posture makes most sense to you. Someone else might "trust alternate people" and another might keep a printed copy of all their passkeys in a bank vault. But whatever you choose as your preferred recovery/bootstrap method, using that to get you to a per-site passkey world makes you safer than what you're currently doing using symmetric keys everywhere.

[compiler-guy]

> Trust the security experts when they say passkeys are more secure.

I trust the security experts when they say passkeys resist various attacks better than current systems...

> Now, solving the UX to make it match that of passwords plus managers today is the problem, agree.

... but poor UX makes it likely the users will end up doing things that are less secure, not adopting them at all, or messing things up themselves in such a way that they lock themselves out of their accounts.

So until the UX issues are fixed, "more secure" only in the narrow definitions that sophisticated security folks worry about. If the folks I support blow it, it doesn't matter that some mostly theoretical MITM attack was prevented.

[dcow]

Understood completely. I was only trying to articulate that there are tangible security benefits to using passkeys over passwords and no/zero theoretical downsides. A 32byte random password is just an edDSA private key that's not private, after all, and the two can be managed the exact same way with none of the device-bound woes. That is, all assuming that platform vendors commit to providing the same affordances for passkeys as they do for passwords in terms of allowing users to delegate to 3rd parties to complete signing of the WebAuthN challenge.

I also believe that Apple/Google/Microsoft understand the importance of not having a "I lost my device all my stuff is toast" UX, which is why Apple requires iCloud keychain to enable passkeys. They are making a pretty strong statement that the UX they imagine working for the masses is not some rigid "no cloud no syncing not here not ever" stance. So I think they realize it has to be a solution that doesn't have that failure mode. They're okay with soft keys, which is at least a relief.

[lxgr]

> The solution, for you, is a cloud synced passkey manager

This is in fact the only possible solution you get on iOS, and the default solution on Android.