[awaythrow98765]

Those passkeys are either insecure or unreliable. Let me explain:

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.

[015a]

It would be a bad and dangerous idea, if what you said was true; but it isn't.

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.

[Ajedi32]

> Now one could allow backups of a passkey

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?

[awaythrow98765]

> 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.

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.

[lxgr]

> 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.

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).

[Ajedi32]

You seem to be under the false impression that passkey databases are stored completely unencrypted and unprotected on disk or in the cloud. Obviously those details are implementation-dependent, but I don't know of any passkey implementation that works that way.

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...

[jmbwell]

As an administrator, I hear you, but we have to adapt. Passwords are awful. On the whole, the effort and energy spent training people on passwords, battling phishing, dealing with password managers, cleaning up from breaches, and more… passwords can't die soon enough.

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.

[JohnFen]

I'm looking forward to such glory days. Right now, however, none of the solutions available are ones that I could live with if I had to use them for everything. For one or two very sensitive things, sure, but for everything? It's less of a pain to use long, random passwords.

[jmbwell]

This is just like using a long random password, except that it's cryptographically verifiable without ever leaving your device.

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.

[jmull]

> you cannot make a backup of it

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.)

[judge2020]

Maybe for browsers on Windows it'll default to storing the key purely on-device, but especially with iCloud Keychain the key is not encrypted by the on-device processor.

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-...

[Shank]

The point of passkeys isn’t to be perfect — the point is to replace passwords, which are already far more imperfect than passkeys. The bonus points with a password is that every site that uses them has to secure them properly and theft of passwords, in plain-text, hashed, etc form is common.

[awaythrow98765]

For an end-user, reliability and ease-of-use trump security. Passkeys are imperfect in the wrong places imho.

[XorNot]

Imagine for a moment that instead of all the time wasted on this, we just implemented a protocol amongst the browser makers which allowed a secure password prompt to be requested, and required strong-hashing before sending anything over the wire?

Which would be easier to use and more effective.

[doodlesdev]

If you hash before sending anything over the wire then the hash of your password is now your password, meaning that if it leaks it amounts to basically the same as your password leaking. Granted, applications may choose different hashing algorithms, provide their own clientside salts, etc. which would be really nice. To be fair, I believe more systems should be doing this nowadays, it's really weird to have to send your actual password to the website if a hash would suffice. Then the website could store the salted hash of the salted hash of your password in their database.

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.

[XorNot]

If a common browser protocol required the password to be salted with an application supplied value and then rehashed with the domain name it's served on, there'd be no way to phish a password.

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.

[seti0Cha]

The idea seems to be that you will either trust a provider like Apple or Google to keep you private key safe and let them sync it around, or you will create a passkey for each device that you use. If you lose the device, deauthorize the passkey. If you somehow lose the passkey itself, create another one, either by using an older form of authentication, or by creating using a different device to authenticate. There is no need for passkey recovery or backup.

[boudin]

I find this to be a regression in terms of usability and security as well.

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.

[lxgr]

What would be a better idea, then?