I think that's what you're getting at in paragraph 3?
There's no reason you couldn't have an open source passkey manager that allows you to backup and view the key if you really want to. SSH works just fine that way.
The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
Perhaps this is something I shouldn't be feeling, but this bothers me and I do not know why.
I can see that you might not want it exposed to the user to prevent social engineering but at the same time, if I can't view then I don't feel like I actually own it. Is there a mechanism that might exist to help me not feel this way? I am totally new to passkeys as a concept as well, but I understand the larger goal.
https://github.com/keepassxreboot/keepassxc/issues/10407
When it comes to Apple, or Google, remember that people keep their accounts (and therefore access to their keys) at Apple or Google’s pleasure; people’s lives can and do get upended when Google decides you’ve done “The Bad” and they revoke your account-and there’s no learning what you did. For your, and everyone else’s, security of course.
The desire for better metadata is good, because you don’t want to hand your password for microsoft.com to microsolt.com when you’re in a hurry and a sophisticated phishing email arrived. Still, as an example, I’m trusting 1Password less and less. They just helped me autofill credentials somewhere they shouldn’t have (thankfully to no ill effect) when the password was correctly set up with website information, basically where something was site1.example.com instead of othersite.example.com. Because they ignored the subdomain.
Their response from support? “By default 1Password doesn’t take into account subdomains when suggesting an item…” and if you’re using their desktop product, there you can go change - per-item (wtf?) - whether it requires exact domain match to fill.
As so many other people here are saying, it feels like a mass lock-in attempt. If it’s not FIDO is doing a really good job making it look that way, especially with “attestation” (which could just be Web Integrity 2.0 if misused).
Do you have a source for this? After reading the W3 spec[0] this seems entirely antithetical to the Passkey model and additionally raises concerns about the integrity of hardware mfa devices.
That's simply false, and there are passkey managers that allow this - KeePassXC for example.
This part right here is what I fear the most about Passkeys. I've read too many horror stories of people getting banned from Google (often for no valid reason) and losing access to all of their data. It is absolutely insane to hand over all your passwords to a company like this.
Best practice is to register two keys to every website. Keep one physically in a safe.
With password managers I would say the same basic practice applies. Make sure you have a working offline backup of whatever secrets you hold dear.
There are some sites that only allow you to register a single passkey for an account (AWS Console last I checked) but these should be getting fixed as it becomes more popular
Well, this sounds convenient. Keep the second one in a safe, but register a key to it for every website you use.
Is this a practice we actually believe users will carry out?
I don’t bother with a safe. I have one key that never leaves my home desk and another I have on my keychain. It’s trivial to register the second key when I am home.
Yes it is less convenient than a digital passkey but there is absolutely no way for a remote attacker to compromise it
There are so many apps that don't get this right. Make a login on the website, store it in 1password, and then try to login in their mobile app and it doesn't show up as a password because the associated URL is mismatched on the mobile app. Like mybank.com and auth.mybankmobileapi.com
Better yet, while on mobile, search for the entry of the desktop site and have it fill. 1password will ask if you want to update the entry for this site
I think, finally, that the reason this feels so dirty-apart from companies and lock-in and all-is that it’s taking the “something you know” as one auth factor and turning it into something that, not only do you not know, the big goal of is to make sure you can’t know but something you have.
This is a deep, fundamental flaw in passkeys. It's just another example of enshittification disguised as denying end-user control "for their own good." There is no for-profit organization anywhere that I trust more than I trust myself, and there's no threat model where it's more likely I'll be socially engineered into giving up my long random password than that I'll suffer data loss.
I have vaultwarden at home but I don't use it because I just know I'll fuck up my tunnel while I'm travelling or something.
This is my threat model: "hi mum. I need you to drive to my house and fish a keyboard out of the cupboard. Plug it into the big black box and type exactly what I tell you..."
At least that's how I understand it.
SSH keys are asymmetric such that I can make a public half available publicly and then use that to generate signatures of any challenge the server sends.
With passkeys either the server needs to store the value raw(making it susceptible to data breaches or malicious actors), or store the hashed value(making it impossible to do a challenge-response, and making it susceptible to MITM/replay attacks).
It seems to be all the downsides of SSH keys(aka losing it having implications), with none of the upsides, plus additional downsides(hardware devices can only generate 25 unique ones instead of using 1 and sending the public to all services with confidence it hasn't exposed any private info).
But not the second: on Github for example you can have multiple passkeys for the same account.
People mention the "only a single passkey instead of multiple passkeys" issue because they run into some websites such as PayPal that only let you add one passkey. E.g. :
https://old.reddit.com/r/yubikey/comments/14h0d7y/single_key...
https://www.paypal-community.com/t5/Managing-Account-Archive...
Vaultwarden + bitwarden client apps (for desktop/browsers) have passkey support, and i've been using them for a month or two without any issues.
That being said, bitwarden client apps for android and ios are going through a rewrite (from xamarin to native iirc), and are yet to support passkeys. However, the bitwarden folk said passkeys are the next feature coming to these apps.
https://github.com/bitwarden/server
Like the other commenter mentioned, vault warden is the independent server version that doesn't require any of that.
With passwords and logins, it seems like there are far too many edge cases to draw a hard line to say they are locked in the password manager forever. Having a way to copy it out, or export, is also a way to ensure portability, if the password manager being used ever becomes bad and a different option is needed.
Password managers put users in a vulnerable position, as once a user is invested, they've got you by the short hairs. The thing that keeps this from being a big problem, is that there is always a way out. Eliminating this way out, or raising the barrier to exit, can temp these password managers to extort their users, which is not good.
This is a huge difference from regular passwords, and the source of a lot of confusion about lock-in.
You can’t easily move a passkey out of the service managing it—true. But you should be able to easily add another passkey from another service. Then you deactivate the first passkey.
It’s a different mental model and the key is in the name. Passkeys are like keys. You can have more than one.
Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password.
By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain. They provide no way for you to copy and paste the passkey into a website, as you can with a password; there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy.
A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login to a website, but the website has no way of knowing/proving whether that happened; they just get the password.
You reset your passkey the same way you reset your password, because passkeys are just passwords that have to be managed with a password manager. Some sites make it easy to reset your password, some make it hard. You know the drill; there's nothing new or different there.
If you're happy with your password manager, there's no real need to switch, but even very "sophisticated" password users have been known to fall prey to social-engineered phishing attacks.
Are you sure you're never going to copy-and-paste your password into the wrong hands? I don't trust myself that much.
Passkeys can make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager. I think all the password managers kinda like that, and there's something good and bad about it.