[lucumo]

> Until I needed to login on another device and then Dashlane saved that passkey too, but each passkey was tied to the specific device… only it wasn’t clear when I logged in which passkey I should choose, and chose the wrong one and it doesn’t work.

I'm not sure if that has changed since years ago (when you last tried), or that that is a Dashlane thing. In any case, that's not how it is now. I've stored them in 1Password. I can use them on any 1Password-enabled browser, and on my Android. They're slightly easier than password flows, and much easier than MFA flows.

> I’ll also add. I don’t have a good mental model for what a passkey is or how it works.

It's a public and private key-pair. You keep the private key, the server gets the public key on registration. When you login the server sends a challenge. "You" encrypt it with the private key and send it back. The server uses the public key to verify and boom, you're logged in.

[scrollaway]

I remember being a kid on the internet 20-something years ago, understanding how passwords worked, and thinking the whole of the internet must be crazy for accepting a "pinky-promise we don't store that secret password you're sending us in plaintext, let alone use it for nefarious purposes" as the status quo.

I then discovered SSH and how it worked, asked in some public forum why there isn't a way to log in to websites using an ssh keypair, and was ridiculed for it.

Ah well, glad times change.

[pmontra]

I defend against that scenario by letting my password manager generate a different random password for every site. It defends also against sites handling passwords in terribly wrong ways, hacks, leaks, etc.

[diggan]

> I then discovered SSH and how it worked, asked in some public forum why there isn't a way to log in to websites using an ssh keypair, and was ridiculed for it.

In an alternative universe, the web standardized something like "tripcodes but cryptographically secure" which would keep any secrets out from servers, and we'd just be dealing with signed data.

One could always dream :)

[brazzy]

Client certificates are a thing and can in principle be used for authentication on websites. Not 100% sure that was possible 20 years ago, but Istrongly suspect that it was.

The problem is the UX around handling the certificates. Password are nearly impossible to beat in terms of "works everywhere without requiring any support infrastructure".

[skydhash]

Even with SSH, you need access to the console when things went awry. But that’s easier to secure as you need to be physically present in front of the machine, or go through your cloud provider’s security mechanism.

But that’s only inconvenient when you want access back. Most B2C don’t care about you enough to offer those processes.

[hedora]

That’s a poor mental model for how it works.

If it was just a private key that I had, then import/export would be trivial.

[lucumo]

KeepassXC seems to have included that for two years now: https://github.com/keepassxreboot/keepassxc/pull/8825 (I don't use Keepass, so I can't attest to how well it works.)

There's a JSON example of an export on the page. It shows nicely what's stored on your machine.

It's a non-standardized format, because a standard is still being worked on. I think most vendors are just waiting for that. The FIDO Alliance has a news message about it: https://fidoalliance.org/fido-alliance-publishes-new-specifi...

In the article they mention they are not just going to support exporting passkeys, but also passwords and other credentials. The goal is to create a secure exchange format for that. They have published drafts of the standards.

[clysm]

It is that trivial. The problem is vendor lock-in and no common, defined way to export/import them securely (which is going to change soon).

[wavemode]

Perhaps eBay themselves were restricting use of a given passkey to a specific device