[myspy]

I think I'm a tech guy and know my fields. I still have no real clue how passkeys work, how it is better, what it really is.

When your security feature is not as simple as - remember a name and a password and store it somewhere safe - it doesn't work.

Something about keys that are on devices. But what happens when I use a phone and a pc? How to get access then? Do I need a User/PW for the first time? Or do I need one of those keys I have to plug into the device first?

[4ad]

Passkeys are exactly like SSH keys. You should use them exactly like you use SSH keys.

[tux3]

"Exactly" is under a lot of strain here.

SSH is nice because you don't have to think about it. Your private key sits in your .ssh folder, and then everything is transparent. You _can_ put an SSH key in a smartcard if you want, but you have to opt-in to this kind of pain. And even if you do, almost all SSH servers will support that login method without issue.

Passkeys don't sit in your .passkey folder. Your browser doesn't look for passkeys in a standard folder at all. You don't just do passkey-keygen like you would ssh-keygen and forget about it.

Websites might support various combinations of FIDO/U2F/TOTP security keys, your USB security key might support various combination of FIDO2/CTAP/WebAuthn, and the user will be left confused what any of this mess means, why there are so many competing standards, and why they're asked to scan a QR code when they plug in their dongle, and it doesn't just work at all.

[bradley13]

Passkeys ought to be exactly like SSH keys. Unfortunately, they are not.

The attempts to restrict when and how they are stored, and how you can access them - those are going to cause a lot of pain and confusion.

I have all of my SSH keys stored in KeepassXC, which (imho) is a lot more secure than having them hang around in my .ssh directory. Open KeepassXC, and the keys are available. Close it, and they're gone. Synchronizing the KeepassXC-file across devices means that I have access to the keys on all of my devices.

The big companies pushing passkeys are trying very hard to prevent this kind of convenience.

[brabel]

They shouldn't be exactly like SSH keys. With SSH keys, you can go and copy/paste your private keys on a scammer's website because they asked you nicely. People will totally do it as they don't understand what they're doing. The main thing with passkeys, and key dongles in general, is that you simply can't do that as the keys are inaccessible and you can only prove possession of a key when asked by a domain you've explicitly registered with (the proof-of-possession is never sent to any other domain than that which you registered with). What OP says is that opens the possibility for key providers to lock-in users, as that seems like an unavoidable side-effect of the legitimate goal of preventing phishing (phishing is the biggest security issue today, to increase security means making phishing impossible, so I still support passkeys as the best solution for that).

[Spivak]

There's a big difference between "can't just hit the copy button and paste in the key" and "can't export the key as part of a backup." Physically preventing users from ever accessing their own keys is an absurd user-hostile proposition. Even more absurd when the they're software keys stored in a database the user can decrypt. The FIDO alliance is just ensuring that password managers will require 3rd party backup tools to be useful.

Password managers have prevented phishing just fine by binding passwords to particular domains, ssh keys prevent phishing with IdentitiesOnly and passkeys are bound in the same way as regular password managers.

[vel0city]

> ssh keys prevent phishing with IdentitiesOnly

There has been a pretty insane number of times I've asked someone for their SSH public key and I get a response of ---- BEGIN RSA PRIVATE KEY ----. From people employed in tech jobs. Now imagine someone who barely understands how to use a computer, they're an easy target to get their identity phished.

[brabel]

Any security solution that involves lay people having access to keys is NOT secure. What you call "absurd user-hostile" is actually basic security in the real world with non-technical people.

Technical people can already be secure using appropriate protections, but even for them it's very difficult to do it properly.

Lay people will, without understanding what they're doing, ask the password manager to give them their password to enter manually on any phishing website as they'll think that it's not working because it's "broken". So , absolutely no, password managers do NOT prevent phishing.

If you think I am exaggerating, well, I work with this and I assure you it's even worse than that.

[Spunkie]

I would say the exact opposite, traditional ssh key management should eventually give way to resident keys. Aka, treating them just like passkeys.

We've been storing ssh keys directly on our yubikeys since before passkeys were a thing.

Not only is it clearly more secure it's also been a usability lift. Plugin your yubikey, start an ssh agent, and run ssh-add -K to get all your resident keys added to your current session.

[Ferret7446]

I might add, you can already do this. OpenSSH has had FIDO support for a while now. I've found it to work better than trying to use PGP or PIV/PKCS#11

[cyborgx7]

If they are exactly like SSH keys, then why not just keep using SSH keys. Clearly, there is something else to them.

[whereismyacc]

SSH keys are clearly not a feasible authentication method for non-technical users. Passkeys are here to replace passwords, not ssh keys.

[cyborgx7]

I understand this, but the person who responded said Passkeys are exactly the same as SSH and used the same, when asked what they are. If that was true, then we would just teach non-technical users to use SSH Keys.

[vaylian]

What about storing/backupping/managing passkeys versus SSH keys?

[4ad]

It's the same, you should not store or backup SSH Keys.

[carstenhag]

So I should get locked out of all services when my device breaks?

[dwattttt]

You should produce a key per device, and produce a backup key that is safely stored & not used anywhere.

You can recover if you lose all devices via your break-glass backup key, and you limit the blast radius of "my key got stolen" from rotating all your keys to just a single device (or maybe the more likely "I screwed up and pushed my key somewhere public")

[crote]

... which is completely nonviable if you connect to more than a single service.

I agree that you should use a different key per device, but when you connect to over a dozen different services/machines it quickly starts to become a serious chore to add another key. Have fun spending an hour enrolling your new device - provided you can even remember every single usage it should be enrolled with.

[red_trumpet]

I have to store them on my disc, in order to use them tomorrow.

[Spunkie]

Oddly enough you don't. We've been storing our ssh keys(ed25519-sk) as resident keys for years now without issue.

So basically we've been storing ssh keys directly on yubikeys the same way passkeys are stored since before passkeys were a thing.

It seemed a clearly superior option compared to letting ssh private keys roam around on random computers.

[tsimionescu]

Sure, but then limits you to a handful of keys. The WebAuthn people don't like this, they want one key per service, so basically YubiKeys no longer really work with WebAuthn (unless you're fine with only ever using a max of 25 services).

[redeeman]

and then the real world comes knocking

[fellerts]

Can you elaborate on this? Why not?

[planede]

For me that means having multiple keys in `authorized_keys` for the same user and never transferring private keys between devices. From what I gathered from the discussion here, this is not a given.

[nottorp]

So how can i scp my passkey to another machine?

[landmass]

Why would you want to? Just create a new passkey on the other machine. If you're saving them in a password manager, just create a new entry, "Another Machine's Passkey."