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.
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.
Choose a passkey provider that supports this then. I use bitwarden. Other people use iOS keychain. Both work great.
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.
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.
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:)
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.
(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)
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.
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.
Last time I checked, the Bitwarden Vault export included the whole FIDO credential including the private key.
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.
It's worth noting this is also supported in iOS and macOS.
Settings > General > AutoFill & Passwords
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.
Except in all the ways that matter: they are not accessible to users, they are tied to third-party vendors.
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?
I actually built a small web application that’s entirely passwordless, and it works really smoothly. I don’t get the antipathy towards Passkeys.
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.
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.
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.
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.
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.
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?
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.
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.
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…
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.
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)"?
"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".
It’s clearly not (just) a security but a lock-in feature.
> Passkeys are essentially site-specific cryptographic keypairs, which are fine, combined with big tech company paternalism, which is intolerable.
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.
> 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.
This is, of course, also the thing that makes passkeys uniquely unphishable.
It's uniquely excessive, rather than uniquely capable.
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
Designing a system that is secure, scalable, and works for billions of people worldwide in a highly adversarial environment is freaking hard.
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.
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.
Why should we even need a third-party provider? Imagine needing a third-party "provider" for your own ssh keys.
My example was only to point out that there exist self-hostable passkey providers.
When I use passkeys on a single device, the "provider" is the OS, same as with my SSH keys.
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
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).
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.
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.
How do I ensure I can access my accounts if my phone-containing-passkeys is lost/stolen/dies without 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.
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?
> 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.