Most active commenters
  • 9dev(7)
  • lxgr(7)
  • troupo(5)
  • NikolaNovak(4)
  • izacus(4)
  • joshuamorton(4)
  • skybrian(3)
  • rcxdude(3)

←back to thread

225 points Terretta | 73 comments | | HN request time: 0.002s | source | bottom
1. troupo ◴[] No.41856125[source]
I came across an opinion I largely agree with: https://mastodon.social/@lapcatsoftware/113308133338196824 and https://mastodon.social/@lapcatsoftware/113308273654667583

> These big tech companies will do anything possible to prevent users from ever actually being able to access their own passkeys.

> Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.

> With passkeys, the big tech companies are executing a coup d'état of authentication, just like they did for HTML itself.

> In the end, they control every protocol, become the gatekeepers for the web.

replies(8): >>41856181 #>>41856189 #>>41856247 #>>41856254 #>>41856772 #>>41862312 #>>41862676 #>>41881156 #
2. NikolaNovak ◴[] No.41856181[source]
So it's not just me!

I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.

If I show up naked, I can login to the system via password but I am conpletely useless with a pass key. And for somebody like myself who uses multiple devices daily (two phones, two tablets, several laptops and desktops), it seems a nightmare to set them all up or maintain:-(

It feels a system designed for those who live by their phone and trust some specific service provider with their life. I'm not in either of those categories :-(. I still don't understand what the "Keepass, "little black notebook", and "good memory" equivalents are.

replies(3): >>41856209 #>>41856253 #>>41856425 #
3. buro9 ◴[] No.41856189[source]
The second one is particularly pertinent:

> Passkeys are essentially site-specific cryptographic keypairs, which are fine, combined with big tech company paternalism, which is intolerable.

replies(1): >>41863587 #
4. portaouflop ◴[] No.41856209[source]
Idk I just set up both - email&password which live in my password manager and then passkeys for convenience - I can just hit a button without thinking and I’m in.

It’s probably different for everyone but in case I have strictly separate devices- so a laptop where I have my work accounts and a desktop for games and some personal stuff.

I don’t really use anything on a regular basis that needs accounts on my personal devices, but that’s probably very weird nowadays…

replies(1): >>41856299 #
5. ratorx ◴[] No.41856247[source]
AFAIK, you can register your passkeys using your own provider (eg. Bitwarden). I’ve not personally used it too much, but the option is there.

The remaining issue is moving the credentials between providers, which is an annoying limitation. But you can always add a different passkey to the site using the provider you want, so although annoying it is not the end of the world…

The original limitation is similar to the usability of actual physical security keys, which (depending on the setup mode) are deliberately designed such that the private key material is not recoverable. Software based keys don’t HAVE to share the same limitation, but it seems more like a missing feature than attributing malice to the creators of the spec.

replies(1): >>41856463 #
6. wolletd ◴[] No.41856253[source]
KeepassXC actually supports passkeys and can be a passkey provider in a desktop browser.

And Android 14 seems to allow changing the passkey provider in the android system as well. With that, the only thing left would be a KeepassXC-compatible app that can serve as provider on android, using the same database as the desktop.

With that setup, I'd be willing to use passkeys exclusively (my phone is still Android 13 and I don't know about app support). I already can't login anywhere (important) without access to my password manager.

replies(2): >>41858212 #>>41862267 #
7. lll-o-lll ◴[] No.41856254[source]
This is an exceptionally cynical take. WebAuthn is an open standard; this new credential transfer spec is the opposite of “big vendor lock-in”. It’s standardising the export-import.

Standards are slow and expensive to create and evolve. They involve endless meetings, discussion and design. However, the outcome is freedom.

The idea that this should have been “extremely simple” is just standard hubris.

replies(1): >>41856421 #
8. sph ◴[] No.41856299{3}[source]
I already hit a button (the Bitwarden icon in my browser toolbar) so I do not see what passkeys buy me, except a terrible hassle the day I want to change password manager.

It is a solution designed to lock people in the Apple/Google walled gardens, and I don't see why everybody is pushing for it.

replies(1): >>41856437 #
9. lapcat ◴[] No.41856421[source]
> This is an exceptionally cynical take.

> However, the outcome is freedom.

This is an exceptionally naive take.

> The idea that this should have been “extremely simple” is just standard hubris.

Why? Export-import of passwords is extremely simple and can be done with copy-paste or CSV. The only thing preventing this with passkeys is the paternalistic idea that users of passkeys should not be allowed to access them directly.

replies(2): >>41856486 #>>41856950 #
10. izacus ◴[] No.41856425[source]
> I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.

There seems to be a lot of misunderstanding of passkeys indeed. They're in no way different than that random password stored in your password manager and can be (with this standard you're commenting on) moved around wherever you want them.

All passkey sites also support fallbacks to just password or other auth mode.

replies(4): >>41856498 #>>41857306 #>>41859826 #>>41867764 #
11. izacus ◴[] No.41856437{4}[source]
Passkeys work fine with password managers like 1Password, KeePassXC, Bitwarden and others, why do you keep repeating this walled garden shtick?

They're literally a cryptostring stored in your password manager just like your other passwords.

replies(2): >>41856517 #>>41867711 #
12. lapcat ◴[] No.41856463[source]
> AFAIK, you can register your passkeys using your own provider (eg. Bitwarden).

Why should we even need a third-party provider? Imagine needing a third-party "provider" for your own ssh keys.

replies(2): >>41856490 #>>41856578 #
13. joshuamorton ◴[] No.41856486{3}[source]
> The only thing preventing this with passkeys is the paternalistic idea that users of passkeys should not be allowed to access them directly.

This is, of course, also the thing that makes passkeys uniquely unphishable.

replies(1): >>41856718 #
14. joshuamorton ◴[] No.41856490{3}[source]
Do you use the same SSH keys on multiple devices? I certainly don't. If you need or wanted to (you don't) you'd need some way to sync them across multiple devices securely.

When I use passkeys on a single device, the "provider" is the OS, same as with my SSH keys.

replies(4): >>41856511 #>>41861598 #>>41862954 #>>41863272 #
15. troupo ◴[] No.41856498{3}[source]
> They're in no way different than that random password stored in your password manager

Except in all the ways that matter: they are not accessible to users, they are tied to third-party vendors.

replies(1): >>41857388 #
16. troupo ◴[] No.41856511{4}[source]
> Do you use the same SSH keys on multiple devices?

Yes. For example, when upgrading or reinstalling a system

> If you need or wanted to (you don't) you'd need some way to sync them across multiple devices securely.

`scp -r`

> the "provider" is the OS, same as with my SSH keys.

And you have full access to ~/.ssh and you can move copy update rename delete them however you like. Without a "Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF)" to move between blackboxes of third-party providers

replies(1): >>41864819 #
17. troupo ◴[] No.41856517{5}[source]
> They're literally a cryptostring stored in your password manager just like your other passwords.

So I can copy paste them somewhere or move them around without "Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF)"?

replies(2): >>41857036 #>>41857384 #
18. ratorx ◴[] No.41856578{3}[source]
If you only want first-party, you can presumably implement the spec yourself and do whatever you want with the data?

My example was only to point out that there exist self-hostable passkey providers.

19. Terr_ ◴[] No.41856718{4}[source]
That's a bit like saying a house fire is what makes your deleted files uniquely safe from recovery.

The sentence is true, as far as it goes... But it's uniquely excessive, rather than the unique minimum sufficient for the task.

20. skybrian ◴[] No.41856772[source]
Unlike your photo collection, passkeys aren’t precious. They’re just meaningless data. You can and should generate additional ones for each password manager you use, so you have multiple independent ways of getting into an account. As long as you can do that, everything is replaceable and there’s no lock-in.

Similarly, I wouldn’t copy a private key for ssh to a new laptop. I generate a new one and copy the public key instead. It makes it easier to revoke access to the old computer.

I do think this new spec will sometimes be useful for populating a new password manager, though.

replies(3): >>41857222 #>>41860188 #>>41863175 #
21. lll-o-lll ◴[] No.41856950{3}[source]
> FIDO Alliance’s credential exchange specifications define a standard format for transferring all types of credentials in a credential manager including passwords, passkeys and more in a manner that is secure by default.

The hint of why this may be just slightly complicated is in that final phrase.

replies(1): >>41857285 #
22. rcxdude ◴[] No.41857036{6}[source]
With Keepass you can, at least. Other ones not so much.
23. jauntywundrkind ◴[] No.41857222[source]
The proposal that any time o create an account o need multiple physical tokens or multiple password managers running is unbelievably stupid & fantastical. This whole project is doomed doomed doomed of this is the model.

I've never seen a single sight suggest this either. Many have set up passkeys, but not one has prompted me to create a second. I have downloaded a lot of backup keys though.

Sorry to be on blast here but every time passkeys come up the "use multiple keys" gets said & it's a joke. There needs to be a flow where I can create a passkey & have it replicate to a bunch of devices automatically; the current proposal that users need to gather all their security tokens & add each one is an absolute promise this technology is going to flop.

replies(2): >>41857772 #>>41860370 #
24. troupo ◴[] No.41857285{4}[source]
> The hint of why this may be just slightly complicated is in that final phrase.

The hint is that they are putting the cart in front of the horse, have decided on an outcome, and now are busy working towards that outcome.

ssh isn't less secure, and yet you can just copy-paste the required files on your own, instead of relying on convoluted protocols for moving data between black boxes.

It reminds of of their "Data Transfer Initiative" which "let's people move their data around easier" but underneath it's just "well, some of data between Google Apple and some other third party services only": https://dtinit.org

replies(1): >>41863271 #
25. mzhaase ◴[] No.41857306{3}[source]
They are different from passwords in that they are never send over the web. They are a private key used to sign a challenge from the site.
replies(1): >>41862919 #
26. izacus ◴[] No.41857384{6}[source]
You can copy paste them using those formats. What are you arguing about here actually?
replies(1): >>41864695 #
27. growse ◴[] No.41857772{3}[source]
> Sorry to be on blast here but every time passkeys come up the "use multiple keys" gets said & it's a joke. There needs to be a flow where I can create a passkey & have it replicate to a bunch of devices automatically

Choose a passkey provider that supports this then. I use bitwarden. Other people use iOS keychain. Both work great.

28. Dagonfly ◴[] No.41858212{3}[source]
Can confirm: Using Android 14 and Bitwarden, I can sign in to github.com using my passkey. It pops up a system dialog where I can select Bitwarden and then my Github username.

Last time I checked, the Bitwarden Vault export included the whole FIDO credential including the private key.

replies(1): >>41861451 #
29. NikolaNovak ◴[] No.41859826{3}[source]
>> All passkey sites also support fallbacks to just password or other auth mode.

Is this a guaranteed thing? Are we saying any account I create cannot be Created with just a pass key; and that no site or service is able to discontinue the password option?

replies(2): >>41862292 #>>41863202 #
30. solarkraft ◴[] No.41860188[source]
I know you’re applying the same model as for SSH keys (and functionally they are very similar) … but I also think 1 SSH key/device is impractical if you have many services to log into and many devices to log in from - which is just the reality nowadays.

Imagine having to use a specific password for each service/device combination. Instead we don’t tie passwords to devices, but to users, to avoid this complexity.

replies(3): >>41860274 #>>41863190 #>>41863395 #
31. skybrian ◴[] No.41860274{3}[source]
It’s certainly not my reality. I have a desktop computer and a laptop that I use ssh from. How many computers do you have?
replies(1): >>41865079 #
32. skybrian ◴[] No.41860370{3}[source]
I bring it up because people claim there is lock-in and it’s not true.

Apple and Google both replicate between devices, so there is some replication, within ecosystems. I only need to create a passkey twice per account so I can use both. It’s not a big deal, though replicating between them would be better.

And so I am clearly not locked in. (Not because of passkeys, anyway.) If people think they’re locked in then it’s a “can’t be bothered” sort of lock-in.

Clearly not fantastical since I’m doing it.

33. wolletd ◴[] No.41861451{4}[source]
Bitwarden (and Lastpass, iirc) support passkeys a little longer than KeePassXC. I'm glad to hear they achieved full integration.

As a keepass database is used by various open source clients from different vendors, it just takes a little longer to get all this done. But I'm sure we'll get there eventually.

34. Terr_ ◴[] No.41861598{4}[source]
> Do you use the same SSH keys on multiple devices?

Assuming you mean client devices, yes, depending on my personal relationship/control of the device. (For servers, the answer is "very yes".)

For example, my personal laptop and desktop may have the same private key, and I will backup/restore that same key onto either of them if they are reinstalled or replaced with new hardware.

However my work laptop gets its own, so that I can more-easily limit what it can access or cancel it in the future.

35. barkerja ◴[] No.41862267{3}[source]
> Android 14 seems to allow changing the passkey provider in the android system as well

It's worth noting this is also supported in iOS and macOS.

Settings > General > AutoFill & Passwords

36. barkerja ◴[] No.41862292{4}[source]
No, this is not guaranteed.
37. creatonez ◴[] No.41862312[source]
> Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.

Can someone explain how this actually works? Are the two backends required to send messages to each other to facilitate a transfer, or is it a simple encrypted export and import? Will it only facilitate transfers to trusted destinations?

38. jandrese ◴[] No.41862676[source]
Personally, I've never met a cloud provider I would trust with holding my secret tokens. It just seems like such a juicy target for hackers. You have to trust that they have done everything right all of the time.
39. dustyventure ◴[] No.41862919{4}[source]
The private keys are not sent to the relying party yet TFA is about a spec to send them over the web.
40. craftkiller ◴[] No.41862954{4}[source]
> Do you use the same SSH keys on multiple devices?

Yes.

> you'd need some way to sync them across multiple devices securely.

I take out my physical keychain and plug in my yubikey. Then, after typing in the password to my yubikey, I can use ssh and pgp until I unplug my yubikey. It is a hell of a lot more secure than storing your ssh keys on disk regardless of whether or not you use a unique key per device. I could lock someone in a room with my computer, my yubikey, and my password, and they still wouldn't be able to copy my ssh key.

replies(1): >>41863134 #
41. ycombinatrix ◴[] No.41863134{5}[source]
pedantic nit: the yubikey is a device so you are arguably using one unique key per device
replies(1): >>41863267 #
42. rcxdude ◴[] No.41863175[source]
For this to be practical, there needs to be a way to enroll non-present devices. Which is technically feasible, but there's no real support for it yet in the standard or in the available implementations. (e.g. with SSH you can have a list of the public keys of all your devices). That would make e.g. passkeys on a HSM more feasible, since you could enroll your backup in a safe whenever you create an account with your daily driver one.

(The added bonus security feature being you could revoke your daily driver if you lose it, while retaining access to your backup. But again there's no actual support for this kind of thing)

43. rcxdude ◴[] No.41863190{3}[source]
It's not particularly impractical for SSH: have a text document with the public keys of all your devices, and copy it into the authorized keys for any system you want to log into. Passkeys don't have an analog for this, though.
replies(1): >>41863379 #
44. 9dev ◴[] No.41863202{4}[source]
It is by necessity; at the very minimum, you’ll need an OTP via email, since you need an out-of-band method of identifying the user during the registration.

I actually built a small web application that’s entirely passwordless, and it works really smoothly. I don’t get the antipathy towards Passkeys.

replies(2): >>41864825 #>>41867776 #
45. craftkiller ◴[] No.41863267{6}[source]
Haha technically true, but I don't think that was the kind of device they were referring to. Even so, it is possible to use the same key on multiple yubikeys. You generate a PGP key on a secure computer and then load that key onto multiple yubikeys. Then you use gpg as your ssh agent. But this is less secure than using keys generated on-device by the yubikey because your private key exists (hopefully temporarily) as a file on the computer where you generated it.
replies(1): >>41864633 #
46. 9dev ◴[] No.41863271{5}[source]
SSH keys are a massive security liability. A private key, readable by any process you execute, without you noticing, that acts as a key to the kingdom? Maybe protected by a weak passphrase - since you probably have to enter that often - an attacker can brute force at their own discretion after copying it? A heap of public keys belonging to god-knows-which-machine, copied manually to every other server?

Designing a system that is secure, scalable, and works for billions of people worldwide in a highly adversarial environment is freaking hard.

replies(1): >>41865074 #
47. 0cf8612b2e1e ◴[] No.41863272{4}[source]
I certainly backup my SSH keys. That way if my laptop dies today, I can be up and running tomorrow without anyone else being involved.

How do I ensure I can access my accounts if my phone-containing-passkeys is lost/stolen/dies without backups?

replies(1): >>41863879 #
48. fragmede ◴[] No.41863379{4}[source]
fwiw https://github.com/<username>.keys is a pretty good one for that
49. 9dev ◴[] No.41863395{3}[source]
> Imagine having to use a specific password for each service/device combination. Instead we don’t tie passwords to devices, but to users, to avoid this complexity.

But that is the entire premise of Passkeys—they remove the complexity, because having individual passwords per device is clearly superior to user-bound passwords, if you don’t need to worry about it and it just works. Hence why, to stay with SSH, you shouldn’t use SSH keypairs, but certificates signed by a CA.

50. ◴[] No.41863587[source]
51. Scion9066 ◴[] No.41863879{5}[source]
You don't. Same as a physical key for your home, you have backups.

Whether that's having multiple separate keys/devices registered with your accounts or a single key stored in a password manager, you need to have a fallback plan.

52. joshuamorton ◴[] No.41864633{7}[source]
No this is absolutely what I meant: A passkey and a PGP key function very similarly in this capacity, a passkey for a site can be generated on a yubikey and used across devices in just the same way.
53. FireBeyond ◴[] No.41864695{7}[source]
How does one get a passkey from iCloud into one of these formats?

"You can't take your passkeys from Apple Passwords"

s/iCloud/1Password?

"There's not a way to import/export passkeys"

s/iCloud/Google?

So "you can copy paste them using those formats, if you can get them into those formats in the first place".

replies(1): >>41867752 #
54. joshuamorton ◴[] No.41864819{5}[source]
> And you have full access to ~/.ssh and you can move copy update rename delete them however you like.

I think this comes down to me never having wanted to do a copy or move (I create and maintain new keys when I create new devices) which is exactly the same experience i get with a passkey (and is, generally a more secure experience since my keys cannot be exfiltrated since copying them is implicitly verboten).

55. NikolaNovak ◴[] No.41864825{5}[source]
My antipathy stems from my lack of understanding, I freely admit, but it's a lack of understanding that's despite some modicum of intelligence.

I feel I can take a password and print it on paper, memorize it, save it on a USB stick, tell it to my wife. I feel in control with passwords. Nobody owns them but me.

Passkeys feel like a wild wild WILD west of providers and islands and standards. It feels like if I sign up to a website on my iPhone creating a pass key, it is a nontrivial amount of work and even less trivial amount of knowledge to transfer it to my android tablet or windows pc. Or maybe that's not even a thing and really I need to resign up on those devices? Or i need to authenticate a second device with my first one? So if I sign up to website 1 with my phone and website 2 with my tablet and website 3 with my laptop,if I want to access all of those from all my devices, I now have a fun weekend of syncing or something?

And I have no idea how to help my mother inlaw with it unless it's some "create Icloud and trust apple and pray " system.

More than anything, you prove my and disprove gp's point that passwords are not necessarily always going to be an option for all sites and services. In fact it feels everybody is yelling in my face that passwords are gone and this half baked complex system will be the only thing.

replies(1): >>41867980 #
56. _hyn3 ◴[] No.41865074{6}[source]
> A private key, readable by any process you execute, without you noticing, that acts as a key to the kingdom?

You're lumping together the data and access that SSH keys protect (which might be actually nothing) with the key mechanism themselves. The private key itself can be armored or stored in a Yubikey itself, or you can even use more exotic ways of protecting it.

The public keys can be easily automated while the private keys stay safe somewhere. Systems like SSH Universal Key Manager or Userify are out there (both on-prem, and Userify also has saas) to make maintaining the public keys across huge swathes of servers relatively simple (or sometimes extremely simple).

And not just authentication, but authorization, too (usually through something like sudo or doas). Or you can just roll your own with Ansible or LDAP (not nearly as flexible when dealing with two axis of variations - users and servers, but still doable). SSH keys being easy to manage is extremely important, because when things are hard to manage, people open security holes, either through ignorance or to save time.

So, like all keys, yes, SSH keys can be a massive security liability if not properly secured, but they're not so (intrinsically), or even by default.

replies(1): >>41867806 #
57. NikolaNovak ◴[] No.41865079{4}[source]
Fwiw, I have two phones (work and personal), two tablets (ipad and Android), 4 laptops (primary employer, client, personal, music productions), one main desktop for gaming, 4 intel nuc for various TV's and whatnot around the house and two Intel nuc for experimenting. Plus my wifes stuff.

Everything but employer stuff was cheap on Facebook marketplace. I am a bit on the tail end of my friends and coworkers but not by much. It's always been supremely convenient to be able to choose the form and location of my computing device. The cheap devices are largely disposable - I have several layers of backups. It is this perspective that makes passkeys seem strange, a Cartesian joint of many-to-many between my devices and providers that quickly gets... insane.

(This is in context of Passkeys. If your question is ssh, substantially less:)

58. reshlo ◴[] No.41867182{5}[source]
I’ll answer your question with a question: can you memorise your passkey for a given website?
replies(1): >>41883200 #
59. lxgr ◴[] No.41867711{5}[source]
Have you ever migrated one across password managers yourself? I tried; it currently seems impossible.
60. lxgr ◴[] No.41867752{8}[source]
Apple actually does allow airdropping passkeys across devices and iCloud users!

It’s clearly not (just) a security but a lock-in feature.

61. lxgr ◴[] No.41867764{3}[source]
With a draft standard that we have no way of knowing Google and Apple will implement?
62. lxgr ◴[] No.41867776{5}[source]
Passkeys are like SSNs, drivers licenses, passports, local phone numbers etc.:

They work perfectly well for 95-99% of people, but oh boy are you screwed if you are in the remaining 1-5%…

Unlike for all these other “forms of identification”, there’s a chance passkeys will bridge the remaining gap, but we’re not there yet, hence many people are cautious.

replies(1): >>41867827 #
63. 9dev ◴[] No.41867806{7}[source]
But that's exactly my point; securing SSH keys properly is hard to do right at scale, and Passkeys are a solution to manage key pairs at scale.
64. 9dev ◴[] No.41867827{6}[source]
A lot of people here seem to ramble about this, apparently without ever having actually used Passkeys themselves: They are nothing like SSNs, driver licenses or other static IDs. A Passkey is generated per device/site combination, where the client holds the private key, the site receives the public key, and the user can optionally share their private key among user devices depending on their client software. That's all it is. How are you "screwed", and what does it even mean "they don't work perfectly" for you?

What's more, passwords work well for a much smaller percentage that has learned to use password managers. Everyone else is subject to regular breaches, and suffering. This is a problem Passkeys get rid of entirely. There is no good argument against using Passkeys over passwords. Not one.

replies(2): >>41867854 #>>41868177 #
65. lxgr ◴[] No.41867854{7}[source]
I know how they technically work.

I was referring to how 99% of people have (or can easily get) an SSN, license etc., but for 1% it’s absolutely impossible for various reasons, so any flow requiring one for non social security or tax declaration purposes is an unnecessary obstruction to them when other alternatives exist.

Don’t ever believe that passkeys will always stay strictly optional. As soon as something works for 99% of potential customers, the 1% can be deprecated for efficiency/security/… purposes.

And I’m even not anti-passkey or anything, I personally like them and will take them over SMS OTPs any day. But they’re just not done yet, and I really hope they get done in a way that works for everyone before they start becoming mandatory in some places.

replies(1): >>41868012 #
66. 9dev ◴[] No.41867980{6}[source]
> I feel I can take a password and print it on paper, memorize it, save it on a USB stick, tell it to my wife. I feel in control with passwords. Nobody owns them but me.

But reality is exactly the opposite: You don't own your passwords. You hand it out freely to sites you create an account with, and rely on those sites to store the passwords securely. Many don't; either way, you don't know. Regularly, sites get breached and millions of passwords—including yours—are published. That is the least form of control over credentials I can imagine, lest yourself publishing it online.

Passkeys alleviate this by creating an account/site scoped key pair, and only handing out the public key to the site. Breaching a Passkey-only service is futile, because those public keys don't work anywhere else by design. The only one in possession of the private keys is you; compared to passwords, that's infinitely more control.

> Passkeys feel like a wild wild WILD west of providers and islands and standards.

I don't quite understand why you feel that way; there's a single, open, freely accessible specification, implemented by more and more vendors.

> It feels like if I sign up to a website on my iPhone creating a pass key, it is a nontrivial amount of work and even less trivial amount of knowledge to transfer it to my android tablet or windows pc. Or maybe that's not even a thing and really I need to resign up on those devices? Or i need to authenticate a second device with my first one? So if I sign up to website 1 with my phone and website 2 with my tablet and website 3 with my laptop,if I want to access all of those from all my devices, I now have a fun weekend of syncing or something?

Ideally, you would sign into the service with separate Passkeys per device. A mechanism many sites implement is that you can sign in on a new device by letting the browser show a QR code that you can scan with a previously authenticated device to complete the authentication process. It's really straightforward. And if you don't want that for some reason, you can usually choose to send an OTP to your email or phone and use that for the initial signin, then register a new Passkey for the new device.

I totally see how the burden of making it user-friendly is on the particular site here, and the instruction quality varies between vendors—but that isn't on the technology itself.

> And I have no idea how to help my mother inlaw with it unless it's some "create Icloud and trust apple and pray " system.

If you don't trust Apple, install a password manager like 1Password on her devices and let its browser extension handle the complexity. Source: My mother.

> More than anything, you prove my and disprove gp's point that passwords are not necessarily always going to be an option for all sites and services. In fact it feels everybody is yelling in my face that passwords are gone and this half baked complex system will be the only thing.

I'm sure you're an intelligent individual and would really encourage just reading up on Passkeys and the problem's they're actually solving. Passwords should be gone for a variety of reasons, and Passkeys are superior. While I do see how communication around Passkeys was sub-par, I don't think there can be doubt in how asymmetric cryptography is better than passwords in terms of security and usability, if done properly.

replies(1): >>41875788 #
67. 9dev ◴[] No.41868012{8}[source]
I dunno. Should we then proceed to keep up the awful situation we currently have for the 99%, just to avoid any inconvenience to the 1%? That's not how democratic societies usually work.

What reasons are there for not using Passkeys? So far, the only things in the threads here were vague fears of vendor lock-in by people who apparently overlooked the fact that Passkeys are supported by a lot of password managers other than just iCloud Keychain and Google, including open source software.

What is this 1% that we should sacrifice a clear solution to password breaches for?

replies(1): >>41868349 #
68. izacus ◴[] No.41868177{7}[source]
Yeah, they're more like SSH id_rsa/id_rsa.pub keys you've probably been using for decades.
replies(1): >>41868382 #
69. lxgr ◴[] No.41868349{9}[source]
As I said: Most likely the ideal solution really is passkeys, just not in their current form.

I just wish their governance was a bit more aligned with users rather than just big tech. This would be something where Mozilla could really shine, for example, but I haven’t really seen them in the relevant forums, and they were quite late on WebAuthN as a whole.

Some focus on avoiding lock-in and (somewhat orthogonal to that) enabling non-cloud credential duplication would be great, to name a few remaining issues.

70. lxgr ◴[] No.41868382{8}[source]
That’s exactly the concern many people here have with passkeys in a nutshell:

SSH keys started out as standardized, interoperable plaintext files (with an option to use GPG smartcards or other hardware credentials or custom SSH agents if you need them).

Passkeys are the opposite. And defaults matter.

71. fmajid ◴[] No.41875788{7}[source]
You have an incomplete threat model. What passkeys bring that is new to the table is phishing resistance, when the user is the one that is breached.
72. ◴[] No.41881156[source]
73. xescure ◴[] No.41883200{6}[source]
What’s your point? Can you memorize SSH keys?