Which would be easier to use and more effective.
Programs such as Bitwarden already do this, where you send the hash of your password to the server instead of the password itself, because from the password you derive the decryption key and you never want that reaching the server. You then use that hashed password as the authorization password, but the client uses the actual password to decrypt the delivered password vault.
The value the user's browser sends back can't be reversed, so any website prompting from the wrong domain would only ever see an incorrect hash, rather then the cleartext as it does now.
On top of what you mentioned, it also fails really hard when someone has access to you and your trusted device (which will be the smartphone in most cases). It's already an issue allowing easy access to smartphone content, it will extend it to any account using that method of authentication.
FWIW, asymmetric PKI is technically mature and relatively easy to implement in most applications (without "vendor lock-in", I might add to comments upthread), and there are ways to address most of your concerns about key loss and recovery beyond what you describe, as by the ring of trust scheme Apple uses, for example.
The only way through this is forward. I'm confident it really will get better once passwords become a smelly indicator of bad security practice.
If passwords are like playing poker with your cards facing out, Passkeys are like playing with your cards facing in. Your secrets remain under your full control at all times. Nothing sensitive is sent over the wire.
Yes, for everything. Those who've implemented it so far have done a great job at making it /easier/ than handling passwords.
If you've ever used ssh with keys instead of passwords, it's the same thing, and it's so much easier while being more secure. A rare convergence.
The way this typically works is that the keys are stored in an encrypted file, which can be backed up securely as-is. It can also be copied around and sync'd to other devices.
Of course, this means the authenticator app/service that needs to use the private keys to respond to challenges has to be able to decrypt that file, which means logging in to it. Authenticators balance convenience with security in terms of how often you need to fully log in to it. They are also often configured to require a light-weight authentication on each use (fingerprint, face, pin).
With authenticator apps handling the private keys, secure backups should be easy and automatic. Things should improve since the people using passwords now who don't have a secure automatic backup mechanism for them and switch to passkeys will probably end up with an authenticator that does it automatically.
(Recovery processes will still exist and can still be an issue.)
That's literally part of what makes a passkey a passkey (v.s. just a WebAuthn credential), so that's a given.
> as insecure as a password
No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your monitor. Passwords can. Passkeys can't be reused across multiple sites. Passwords can.
There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".
> One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.
What? Malware stealing your password is "more secure" than malware registering it's own malicious key to each individual site it wants access to?
Passkeys don't need to be cracked after a data breach of your backup provider, they are just usable, right there.
> There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".
Passkeys are accessible permanently on some devices unencrypted or decryptable in the filesystem, if part of e.g. a backup. Whereas passwords are usually only accessible temporarily. That makes the attack surface top copy over some passkey far larger than for sniffing a password.
Let's take Apple's implementation as an example (since that was the one I could most easily find information on). Their implementation stores passkeys in the iCloud keychain[1], which is end-to-end encrypted[2].
[1]: https://support.apple.com/guide/iphone/sign-in-with-passkeys...
[2]: https://support.apple.com/guide/security/secure-keychain-syn...
I think you're mixing up server-side and client/sync-backend-side compromises here.
For the former (i.e. a compromise of hashed passwords and their corresponding salts), you'll need to rotate all passwords since the hashes can be brute-forced. For passkeys, all an attacker gets when compromising a service's database are public keys that can't be brute-forced and key handles that don't give an attacker anything without the corresponding authenticators.
For the latter, the situation is exactly the same for passkeys and passwords in a password manager, i.e. both are as secure as their on-device storage and encryption in transit and rest at a synchronization provider (if any).
This does not make it as "insecure as a password". It does mean you can use root/OS access to exfiltrate keys, but it closes the following security holes that affect passwords:
- keyboard sound-based exfiltration[0]
- visual exfiltration (someone recording you enter your password, or looking over your shoulder and memorizing it)
- credential stuffing, where people who reuse passwords get pwned when the same leaked password is used on other websites
0: https://www.independent.co.uk/tech/cyber-security-passwords-...
Passkeys are just asymmetric key-pairs. There will be a variety of client-side implementations. Some may make export and backup difficult or impossible. Others, such as 1Password's already extant implementation advertise backup and synchronization as a feature! There is nothing about the passkey standard which prescribes the reality you fear.
> Now one could allow backups of a passkey, but then that passkey would be as insecure as a password.
Wrong, absolutely and entirely. Its still more secure, because its an asymmetric keypair, and you're forgetting about the far more common attack vector against password disclosure: service breaches. That's how attackers learn about passwords by-and-large. And this is not just some nice-to-have side-benefit of passkeys: its a core motivation of this standard. With passwords, a service breach compromises not only the accounts of every user on that service, but potentially every other account every user has, globally, because of password sharing. With passkeys, all of that is resolved.
Even if we end up with a system that is the same level of effective client-side security, which is also extremely wrong, the net security of the system will be vastly improved because service providers aren't storing the private key used to authenticate user accounts.
But the client-side security is also substantially improved, because passkeys have much higher phishing resistance.
Those passkeys are asymmetric cryptographic keypairs where the private key is securely stored on a device, unlockable (for use, not reading) only by convincing your devices security processor to do so by pin/fingerprint/pattern. Which in itself can be secure, given you do trust that magic security processor (which you shouldn't, see yesterday's news for example). However, if that key cannot be read, you cannot make a backup of it, so it will be unrealiable and easy to loose. The recovery process will either be insecure and prone to social engineering, or unreliable because proving your identity will be nigh impossible without that passkey. Now one could allow backups of a passkey, but then that passkey would be as insecure as a password. One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.
In all a bad and dangerous idea.