Passkeys will come at a cost

I have hundreds in my password manager.

> Passkeys parasitize on FIDO2 U2F standard

U2F authenticators and the U2F protocol cannot support passkeys. A passkey is a discoverable credential which supports user verification. U2F supports neither discoverability nor user verification.

Passkeys as a user-facing term is meant to describe a user experience. Second factor authentication using U2F is a different experience.

> The problem is that the site has now to trust user’s personal account in one of these platforms and that the user did the right thing and also the platforms will always be doing the right thing - e.g., they will handle attacks on user’s personal account properly.

That is in fact how passwords work today. You can't tell if my password came from my head or from a excel spreadsheet printout I carry around in my wallet; from a cloud synchronized password manager or if I use the same password for every website which will accept it (otherwise, I will add exclamation marks to the end until it does).

This is a bit unrelated to the harder crypto stuff but my mom called me freaking out she couldn’t get into her gmail. It turns out Google auto registered her new android phone with a passkey and made that the default Google login with a confusing passkey based interface (expecting her to know to click the second option to login via password or understand wtf a passkey is was too much IMO).

It turns out when it said “passkey sent to android” the android never got any notification and I couldn’t figure it out after half an hour. You can’t even delete the auto registered passkeys. Nor turn off the default auth flow.

Terrible UX by Google. I’m assuming it’s because her phone is some budget Samsung with a bastardized Android. Trusting those devices on a mass scale to run your auth system was dumb.

Now do the passkey (or is it webauthn?) failure modes. They are a nightmare as outlined in the top post in this thread by dmix.

I agree with your post. I'd just like to add a couple of comments:

> if the provider (bank) is compromised and salted passwords leaked it doesn't matter, they have already compromised the bank and your account.

It matters if the only thing that was leaked/compromised was the hashed password database, but not much else.

In fact, the ones who leak the hashed passwords may not be the same as those who hack your accounts, just look at all the leaks tracked by https://haveibeenpwned.com and consider that anyone could download those hashed passwords and crack them.

> And i still do not think you can quickly crack a password such as "This15aVERY!!securepasswordEH?!!?"? i could be wrong here

You could be right, but I wouldn't be surprised if you were wrong here...

Decades ago, the "John The Ripper" cracker was already very good at cracking these kinds of passwords (when CPUs were single core and much, much slower, and it wasn't even possible to run software on a GPU).

John the Ripper was already capable of using many extremely extensive word lists (in different languages) to quickly run through many such passwords, and simply mutating the password by using l33t speak and adding a few numbers, symbols or using mixed case are extremely popular password strengthening techniques which the software was still capable of cracking very quickly, since that doesn't add much entropy.

Although at the time it probably couldn't crack such a "long" password, I'm sure this type of software has become better and the hardware has definitely become many orders of magnitude faster and more parallel, so I wouldn't be surprised if the example you mentioned is well within "can crack quickly and relatively cheaply" territory, even when using salt, as long as the service is using a traditional password hashing algorithm (and not one of the newer compute-hard or memory-hard KDFs).

I mean, to have an idea of the magnitude of the problem, the brainwallet cracking stories of a decade ago were already pretty mindblowing (even considering that it's a "no salt" scenario).

I don't remember the exact details, but I think there were cases of people using an airgapped computer to compute the SHA-256 hash of some obscure passage of some obscure book or poem in some obscure language and the bitcoins were stolen within seconds of being transferred to these wallets (although, yes, due to the "no salt" problem, it stands to reason that all of these wallets were pre-computed by the attacker).

But still, personally I'd feel a lot more comfortable just using and storing a completely random password with a perfectly known amount of entropy, just to be safe, and deal with the compromised device problem in some other way (such as having a dedicated password management device, like a hardware wallet, if you're really that paranoid).