People keep trying to answer this question, so I'll try, too, but I'm going to do a better job than anyone else. ;-)
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.
I'm assuming tech people would also like to know that a passkey is not just "a really long password" but also one that's never sent to the server directly - instead it's used in a challenge/response protocol (like SSH keys). Which requires software, either the browser or an external password manager, to run.
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.
It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves.
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).
> 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).
That's simply false, and there are passkey managers that allow this - KeePassXC for example.
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.
Personally it bothers me, and I don't want to feel any different. If I can't back it up or share it, it's not something I want to use. It's different than something like TOTP where even though I can't functionally hand-calculate it, I can still move the secret anywhere I want
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).
It feels ... suspicious ... to me that in 2024, we're designing a new authentication scheme explicitly around resident keys, but challenge-response is optional. Credentials in any new protocol should never be sent over the wire, period.
> It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves.
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.
> 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.
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.
I have been using passkeys for a while in the form of yubikeys
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
Yubikey are $50 so if you are already investing real money in your online security it’s not a stretch to expect that people will spend extra time and money to keep a physical backup
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
> 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.
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
1password has a URL field. All you have to do it add the extra URLs
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
Except they ignore subdomains. Unless you fix that on a per-item basis, in their desktop application.
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.
I have been using 1Password for over 15 years and it has the ability to only show/fill passwords when on the correct site. The issue is, over time, companies shift their strategies on the web. URLs change, while the accounts stay the same. I have had to update these details many times. I've also run into situations where the browser plugin isn't functioning, for whatever reason, and the only way in is to copy/paste. There are also times where I'm not on my computer. For example, I usually piggyback on my dad's copy of TurboTax each year. When I'm over there, I will often need to pull up a password on my phone and type it into TurboTax as it logs into my bank to download the tax forms. Passkeys don't sound like they can solve that problem. I'd question if the Passkeys would work in TurboTax even if I was running it on my own computer.
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.
It's not a problem of mental model, it's a problem of scale. If I'm switching phone, the last thing I want to do is to go to every website I have an account on and essentially do a second sign up. This is simply a non-starter, and is a big part of why companies like Apple and Google are pushing for this spec: it nicely ties you in to their ecosystem and gives you a huge reason not to move to a different ecosystem.
I use selfhosted vaultwarden [0] instance (its a rust implementation of the bitwarden server), and the bitwarden apps (i point the apps to use my server instead of bitwarden).
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.
Bitwarden, which you can self-host (I do this) seems to have at least partial support now, and I know they're working on improving it. However, I'm not sure if their client and server are both fully FOSS.
... with some of the functionality of SSH keys removed, like being able to use one key for many accounts, or many keys (on many machines) all for the same account.
>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. :
Unless I'm missing something these are nothing like SSH keys. They would be closer to regular password auth with SSH where you store the password in a file that's only readable by SSH.
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).
> there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy
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.
Good for you; I'm ashamed to say that I've hurt my data sanctity far more than any criminal has, with 2am tinkering with my systems.
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..."
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.