I almost got locked out of my pixel phone after wiping it because Google suddenly required me to 2 factor…using my phone. As a consumer I am extremely skeptical of the “something you have” method of security given how easy it is to lose things.
Using a password manager to log into Gmail with a passkey ensures he’s protected by MFA. Using the password alone does not.
I don’t understand this. If I store my passkey (a site-specific private/public key pair) in Bitwarden, isn’t it just sitting there unencrypted in memory the same as all my other passwords? Sure maybe the app doesn’t let me copy & paste the private key through the UI like with passwords but it isn’t hooking into a local secure hardware element, is it?
Talking myself through it, perhaps Bitwarden will only sign challenges themselves signed by the public key of the relevant site. So I am protected from MITM phishing attacks where I copy and paste my password into the wrong site. Sure the key can be stolen from memory but I suppose that is still an upgrade compared to using a password.
If the key were stored in a secure hardware element instead then we would expect it to rapidly fill up the limited key slots as each site gets a different key. Although perhaps yubico or similar is now offering hardware tokens that can store a large number of these keys. But then can they be securely backed up to a separate hardware token, or are they bound to that one?
Quite a few passkey implementations do use a local secure hardware element; not sure what Bitwarden does, but presumably not.
But passkeys indeed incorporate the site into the authentication. This makes passkeys phishing-proof - you-the-user may be trying to log into mail.g00gle.com, but mail.google.com isn’t going to accept a signature on mail.g00gle.com.
Discoverable (“resident”) passkeys are indeed limited by capacity; the original Yubikey design instead (re-)generates keys on-demand - think ECDSA-KeyGen(KDF(master-key, name-of-site)). The original design is a better fit for hardware with limited storage, but does mean that the Yubikey can’t usefully tell you whether you have a passkey for a particular site.
Registering a new site doesn’t take up any extra physical storage on a hardware key like yubikey — you can have as many sites as you like. I’ve not memorised the exact protocol, but essentially you have a single private key on the USB key which signs a challenge provided by the site in order to authenticate (the site stores a public key for your device). I think they may be deterministically deriving a unique key per http origin so that you can’t be tracked between sites.
You can’t back up/duplicate a hardware token, instead you need to register more than one and keep one in a safe place to bail yourself out if you lose your main one.
IMO the password manager model of syncing pass keys between computers via the network does rather weaken the security properties compared to a hardware key. (In that it can be stolen without physical access.) They do still preserve the property that the credential can’t be phished when authenticating to a site (real or fake), but access to the password manager itself can be achieved with social engineering and potentially with access to your computer.
Sadly, what you’re saying is only true for non-resident keys. Resident keys are actually quite limited, yubikeys support about 10, and to remove one of them you’ll need to reset the entire yubikey.
And sadly Apple and Google made resident keys mandatory for Passkeys.
Because I use a wide assortment of browsers on platforms,
You are not the typical user, my friend. Don’t mistake your use case for the typical use case :-)
I have chosen to sync the passkey using my 1Password password manager
You just lost one of the key benefits of passkeys–the fact that they are sequestered in your platform’s security authenticator and can never be exfiltrated from there. Now, your passkeys are blithely travelling along on the internet, and all it takes is one endpoint that decrypts them to mess up and expose them.
macOS preempts this task with directions for creating a passkey that will be synced through iCloud
Yes this is definitely confusing. But over time as passkeys become widespread and USB dongles go the way of the dodo, it becomes less of a problem.
These are definitely things that unnecessarily confuse and complicate the use of passkeys. But often, they’re one-time events that can be overcome by creating multiple passkeys and bootstrapping them for each device. From then on, these unphishable, unstealable credentials live on both devices,
Exactly! this is the way.
More helpful still is using a cross-platform password manager to store and sync passkeys.
You were almost there, but you veered off into a wrong turn 😂
This reliance on a password manager, however, largely undermines a key value proposition of passkeys
That’s why passkeys should not be stored in password managers. You are so close to getting this. It’s simple: create a passkey on each device you use.
And when you want to switch browser/computer/phone/whatever? “Sorry, gotta rebootstrap tens/hundreds of keys separately from the old device” is not really a viable answer.
You are not the typical user, my friend. Don’t mistake your use case for the typical use case :-)
Every user probably won’t have it happen on a daily basis, but I promise you that every single user will have it happen sooner or later (and probably be much worse prepared for the event).
“Sorry, gotta rebootstrap tens/hundreds of keys separately from the old device” is not really a viable answer.
It’s not a viable question either. You don’t need all those accounts immediately when you switch to a new device. You need one at a time. As long as there is a reasonable sign-in flow with an email token and immediate passkey creation, it’s barely a speedbump for a typical user. Remember, users today don’t even bother to remember passwords. They just use ‘reset password’ as their normal login flow. Passkey + email flow for new device is a vast improvement over the typical flow that users have today.
Remember, users today don’t even bother to remember passwords. They just use ‘reset password’ as their normal login flow.
Really? That is an actual thing? A cursory search suggests to me that it’s at least hyperbolic, but you seem to present it as established well-known fact. This surprises me, so I ask, is it actually a thing?
Also, while true that they don’t need to reset the full set of the services they use overall, they will have to do a bunch right now (their working set, if you will), and then there will be a long tail of bad surprises (oh no, that’s right, I do not have that passkey anymore), which may be confusing and difficult in special and novel new ways every single time.
Yes, this is a thing. I used to work at a large ecommerce retailer and they actually had analytics that showed that users never logged in with their passwords and always just logged in with the ‘forgot password’ flow. Unfortunately this is not really easy to search for but you could try asking around in circles that deal with high-traffic ecommerce 🤷♂️
The flow I am suggesting will sidestep the ‘bad surprises’ by just making it a normal process ‘Oh just enter the token we just sent you and we’ll get you in right away’. The user wouldn’t even perceive it as something abnormal.
And it’s not uncommon for this to be the method provided by the site, with “email magic link” logins. And from a casual user POV, sites often send them auth codes via SMS or email anyway, so it all looks pretty similar.
I cannot confirm that for the services I’ve worked on. Only few people do that.
I take a guess here: the ecommerce retailer probably did something like forcing users to use very complicated passwords with difficult rules (like “use 13 to 18 characters with 2 special characters but no two same consecutive ones” etc.) or force users to change their passwords every other week or ask them to re-enter their password every other day (cookie lifetime) or a combination of those.
Then eventually users just give up and reset their password every time.
many of the people who don’t use password managers use that “forgot password?” flow every time they sign in because people cannot use passwords effectively
If you allow email resets then what’s the point of bothering with the passkey at all? At that point you might as well just set a regular cookie when emailed.
The point is to reduce the dependence on the email flow as much as possible and substitute it with the much better passkey flow. We are just talking about needing an email flow when setting up a new device in the typical situation. We are not ‘at that point’ where we are using it constantly.
Sorry I don’t understand your point. If you get a new device the flow I am suggesting works perfectly no matter whether you later return the device and get a refund, or get a replacement. You just set up the passkeys for the accounts you need with email flow on the device. It should take a few seconds per account, it’s a one-time setup.
You just lost one of the key benefits of passkeys–the fact that they are sequestered in your platform’s security authenticator and can never be exfiltrated from there. Now, you can blithely reset your credentials purely through the internet, and all it takes is one compromised email server, unsavory sysadmin, or other data breach to enroll a key store you don’t own.
On top of that, if I’ve destroyed my phone and I need the passkey that lived on it to get into my email, I have no way to reset my passkeys.
If the best way to use passkeys is to create a separate one on each device we use, why do these various services offer to sync them? Like the iCloud keychain for example.
This also brings up account recovery questions. The only service I’ve seen using something similar to this is keybase and I’ve been locked out of it several times and had to reset my account.
Because people are lazy and don’t want to take the more secure route. I believe it’s a mistake.
When it comes to account recovery, meaning setting up a new passkey on a new device, I believe the best flow is the email flow. Go to the login screen, enter your email, click Sign In. The system sees that you don’t have a passkey set up and responds with a message saying to check your email for a one-time token and enter it in the following box. You enter the token. You then get logged in and immediately prompted to set up a passkey. You set it up and from then on you have the passkey on the device and can use the Conditional UI flow–just click on your passkey and you are logged in.
So because syncing unphishable keys decreases security somewhat (exact degree depends on the implementation ofc, there has been lots of noise and threats about implementations making it “too easy”), we instead train people to expect a less convenient path using phishable one-time codes via email as a normal workflow, and that’s somehow better?
I feel like you are assuming perfect user behavior for the path you like, and assume worst-case behavior for the one you don’t like, at which point whatever you like is the best, fairly obviously.
Yes, we need to have a way for users to recover their accounts. You can’t just leave users with zero access to their accounts if they happen to lose whatever login mechanism they were using, whether it be password, passkey, USB dongle, or whatnot. Any service that permanently locks its users out as a matter of course, is either deliberately targeting a highly technical population (eg 1Password), or they are prepared to just lose the user over this. In your words: you can’t just assume perfect user behaviour. Users will lose access and need a way to recover their accounts.
And since you do need to have an account recovery process, we can at least try to minimize the risk–we are offering this flow only when the user is legitimately trying to log in. This is the only time they will receive the emailed token, and we can make this very clear. If they get an email token any time they’re not trying to log in, that’s clearly a phishing attempt.
Another reason is because it makes the users more sticky. Because it’s harder to leave your vendor’s ecosystem if everything is perfectly set up and synced. And if you want to transfer all your passwords and passkeys to another ecosystem you have to deal with the headache that is exporting and importing them all.
And the solution I described would work fine for them–doing email flow and then setting up the passkey on first login to an account on a new device, then subsequently consistently using passkey on each device that has already been set up. If they are like my mom and have a few accounts they typically use, eg YouTube and Facebook, this will work fine. The new device email flow setup will barely register for them.
You must not have been following the rest of this thread where I mentioned that using ‘forgot password’ flow for non-tech savvy people is a regular login flow. They don’t want to and don’t bother to remember passwords, they just hit ‘forgot password’ and log in through the email. If you don’t believe me, just ask around a bit among non-tech savvy people you know–people who don’t use password managers–about how often they use ‘forgot password’ to log in.
In my case they simply stop logging in, because using the “forgot password” flow mean knowing how to use your email for it.
Which is exactly what passkey would solve, but we do not see it because these are people that stop interacting with your login. What you see has survivor bias.
You are talking about a case where the user does not know how to recover their account in case they would ever forget their password (or lose it if they wrote it down). They are just going to never log in again. So it would be the same situation whether they were using passkeys or passwords. Passkeys were not meant to ‘solve’ this issue. There is no technical solution for the issue of a user not having the basic ability to use the ‘forgot password’ email flow. On the other hand, we need to have an account recovery mechanism for the vast majority of users who can use the email flow.
I have no idea what is being stored where or how I should back it up so I’m refusing to use Passkeys.
I’ve seen plenty of compelling arguments on why to use them, but it’s the ‘how’ that puts me off every time.
A cynic might say that this is done on purpose. Many reductions in user autonomy are disguised as security innovations.
For similar reasons I’m only using passkeys where they are a progressive enhancement (2FA or alternate login method).
I almost got locked out of my pixel phone after wiping it because Google suddenly required me to 2 factor…using my phone. As a consumer I am extremely skeptical of the “something you have” method of security given how easy it is to lose things.
I don’t understand this. If I store my passkey (a site-specific private/public key pair) in Bitwarden, isn’t it just sitting there unencrypted in memory the same as all my other passwords? Sure maybe the app doesn’t let me copy & paste the private key through the UI like with passwords but it isn’t hooking into a local secure hardware element, is it?
Talking myself through it, perhaps Bitwarden will only sign challenges themselves signed by the public key of the relevant site. So I am protected from MITM phishing attacks where I copy and paste my password into the wrong site. Sure the key can be stolen from memory but I suppose that is still an upgrade compared to using a password.
If the key were stored in a secure hardware element instead then we would expect it to rapidly fill up the limited key slots as each site gets a different key. Although perhaps yubico or similar is now offering hardware tokens that can store a large number of these keys. But then can they be securely backed up to a separate hardware token, or are they bound to that one?
Quite a few passkey implementations do use a local secure hardware element; not sure what Bitwarden does, but presumably not.
But passkeys indeed incorporate the site into the authentication. This makes passkeys phishing-proof - you-the-user may be trying to log into mail.g00gle.com, but mail.google.com isn’t going to accept a signature on mail.g00gle.com.
Discoverable (“resident”) passkeys are indeed limited by capacity; the original Yubikey design instead (re-)generates keys on-demand - think ECDSA-KeyGen(KDF(master-key, name-of-site)). The original design is a better fit for hardware with limited storage, but does mean that the Yubikey can’t usefully tell you whether you have a passkey for a particular site.
Registering a new site doesn’t take up any extra physical storage on a hardware key like yubikey — you can have as many sites as you like. I’ve not memorised the exact protocol, but essentially you have a single private key on the USB key which signs a challenge provided by the site in order to authenticate (the site stores a public key for your device). I think they may be deterministically deriving a unique key per http origin so that you can’t be tracked between sites.
You can’t back up/duplicate a hardware token, instead you need to register more than one and keep one in a safe place to bail yourself out if you lose your main one.
IMO the password manager model of syncing pass keys between computers via the network does rather weaken the security properties compared to a hardware key. (In that it can be stolen without physical access.) They do still preserve the property that the credential can’t be phished when authenticating to a site (real or fake), but access to the password manager itself can be achieved with social engineering and potentially with access to your computer.
Sadly, what you’re saying is only true for non-resident keys. Resident keys are actually quite limited, yubikeys support about 10, and to remove one of them you’ll need to reset the entire yubikey.
And sadly Apple and Google made resident keys mandatory for Passkeys.
Thanks for this, I think I’ve mostly used my keys with FIDO U2F, as second factors.
For people who want to know more, Yubico have quite good docs explaining these things: https://docs.yubico.com/yesdk/users-manual/application-fido2/fido2-credentials.html
Yeah, they chose to make “passkeys” the marketing name for resident keys and “security keys” the marketing name for non-resident keys I think.
I mean with things going like this it may take quite some time for us to reach that point.
I still think that passkeys at their current form suits amazingly well in a corporate environment.
You are not the typical user, my friend. Don’t mistake your use case for the typical use case :-)
You just lost one of the key benefits of passkeys–the fact that they are sequestered in your platform’s security authenticator and can never be exfiltrated from there. Now, your passkeys are blithely travelling along on the internet, and all it takes is one endpoint that decrypts them to mess up and expose them.
Yes this is definitely confusing. But over time as passkeys become widespread and USB dongles go the way of the dodo, it becomes less of a problem.
Exactly! this is the way.
You were almost there, but you veered off into a wrong turn 😂
That’s why passkeys should not be stored in password managers. You are so close to getting this. It’s simple: create a passkey on each device you use.
And when you want to switch browser/computer/phone/whatever? “Sorry, gotta rebootstrap tens/hundreds of keys separately from the old device” is not really a viable answer.
Every user probably won’t have it happen on a daily basis, but I promise you that every single user will have it happen sooner or later (and probably be much worse prepared for the event).
It’s not a viable question either. You don’t need all those accounts immediately when you switch to a new device. You need one at a time. As long as there is a reasonable sign-in flow with an email token and immediate passkey creation, it’s barely a speedbump for a typical user. Remember, users today don’t even bother to remember passwords. They just use ‘reset password’ as their normal login flow. Passkey + email flow for new device is a vast improvement over the typical flow that users have today.
Really? That is an actual thing? A cursory search suggests to me that it’s at least hyperbolic, but you seem to present it as established well-known fact. This surprises me, so I ask, is it actually a thing?
Also, while true that they don’t need to reset the full set of the services they use overall, they will have to do a bunch right now (their working set, if you will), and then there will be a long tail of bad surprises (oh no, that’s right, I do not have that passkey anymore), which may be confusing and difficult in special and novel new ways every single time.
Yes, this is a thing. I used to work at a large ecommerce retailer and they actually had analytics that showed that users never logged in with their passwords and always just logged in with the ‘forgot password’ flow. Unfortunately this is not really easy to search for but you could try asking around in circles that deal with high-traffic ecommerce 🤷♂️
The flow I am suggesting will sidestep the ‘bad surprises’ by just making it a normal process ‘Oh just enter the token we just sent you and we’ll get you in right away’. The user wouldn’t even perceive it as something abnormal.
And it’s not uncommon for this to be the method provided by the site, with “email magic link” logins. And from a casual user POV, sites often send them auth codes via SMS or email anyway, so it all looks pretty similar.
I cannot confirm that for the services I’ve worked on. Only few people do that.
I take a guess here: the ecommerce retailer probably did something like forcing users to use very complicated passwords with difficult rules (like “use 13 to 18 characters with 2 special characters but no two same consecutive ones” etc.) or force users to change their passwords every other week or ask them to re-enter their password every other day (cookie lifetime) or a combination of those.
Then eventually users just give up and reset their password every time.
If we are listing personal anecdotes then here’s another one from someone who manages the auth flow at Apple: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
[Comment removed by author]
If you allow email resets then what’s the point of bothering with the passkey at all? At that point you might as well just set a regular cookie when emailed.
The point is to reduce the dependence on the email flow as much as possible and substitute it with the much better passkey flow. We are just talking about needing an email flow when setting up a new device in the typical situation. We are not ‘at that point’ where we are using it constantly.
But what’s the concrete benefit?
That makes it worse – when can I return the device for the trade-in refund? What if I got the new device because I accidentally destroyed the old one?
Sorry I don’t understand your point. If you get a new device the flow I am suggesting works perfectly no matter whether you later return the device and get a refund, or get a replacement. You just set up the passkeys for the accounts you need with email flow on the device. It should take a few seconds per account, it’s a one-time setup.
You just lost one of the key benefits of passkeys–the fact that they are sequestered in your platform’s security authenticator and can never be exfiltrated from there. Now, you can blithely reset your credentials purely through the internet, and all it takes is one compromised email server, unsavory sysadmin, or other data breach to enroll a key store you don’t own.
On top of that, if I’ve destroyed my phone and I need the passkey that lived on it to get into my email, I have no way to reset my passkeys.
https://lobste.rs/s/ieig85/passkey_technology_is_elegant_it_s_most#c_5hng1b
If the best way to use passkeys is to create a separate one on each device we use, why do these various services offer to sync them? Like the iCloud keychain for example.
This also brings up account recovery questions. The only service I’ve seen using something similar to this is keybase and I’ve been locked out of it several times and had to reset my account.
Because people are lazy and don’t want to take the more secure route. I believe it’s a mistake.
When it comes to account recovery, meaning setting up a new passkey on a new device, I believe the best flow is the email flow. Go to the login screen, enter your email, click Sign In. The system sees that you don’t have a passkey set up and responds with a message saying to check your email for a one-time token and enter it in the following box. You enter the token. You then get logged in and immediately prompted to set up a passkey. You set it up and from then on you have the passkey on the device and can use the Conditional UI flow–just click on your passkey and you are logged in.
So because syncing unphishable keys decreases security somewhat (exact degree depends on the implementation ofc, there has been lots of noise and threats about implementations making it “too easy”), we instead train people to expect a less convenient path using phishable one-time codes via email as a normal workflow, and that’s somehow better?
I feel like you are assuming perfect user behavior for the path you like, and assume worst-case behavior for the one you don’t like, at which point whatever you like is the best, fairly obviously.
Yes, we need to have a way for users to recover their accounts. You can’t just leave users with zero access to their accounts if they happen to lose whatever login mechanism they were using, whether it be password, passkey, USB dongle, or whatnot. Any service that permanently locks its users out as a matter of course, is either deliberately targeting a highly technical population (eg 1Password), or they are prepared to just lose the user over this. In your words: you can’t just assume perfect user behaviour. Users will lose access and need a way to recover their accounts.
And since you do need to have an account recovery process, we can at least try to minimize the risk–we are offering this flow only when the user is legitimately trying to log in. This is the only time they will receive the emailed token, and we can make this very clear. If they get an email token any time they’re not trying to log in, that’s clearly a phishing attempt.
Another reason is because it makes the users more sticky. Because it’s harder to leave your vendor’s ecosystem if everything is perfectly set up and synced. And if you want to transfer all your passwords and passkeys to another ecosystem you have to deal with the headache that is exporting and importing them all.
My mom and my grandma use daily 3 different OS and browsers. They are a typical user.
Windows/Firefox desktop, android/chrome tablet, iOS/safari smartphone.
This is a real problem.
And the solution I described would work fine for them–doing email flow and then setting up the passkey on first login to an account on a new device, then subsequently consistently using passkey on each device that has already been set up. If they are like my mom and have a few accounts they typically use, eg YouTube and Facebook, this will work fine. The new device email flow setup will barely register for them.
You realise that using emails to get access to their account is a tall order for them? And one of the things passkeys offered to solve?
You must not have been following the rest of this thread where I mentioned that using ‘forgot password’ flow for non-tech savvy people is a regular login flow. They don’t want to and don’t bother to remember passwords, they just hit ‘forgot password’ and log in through the email. If you don’t believe me, just ask around a bit among non-tech savvy people you know–people who don’t use password managers–about how often they use ‘forgot password’ to log in.
I think you miss what I am saying.
In my case they simply stop logging in, because using the “forgot password” flow mean knowing how to use your email for it.
Which is exactly what passkey would solve, but we do not see it because these are people that stop interacting with your login. What you see has survivor bias.
You are talking about a case where the user does not know how to recover their account in case they would ever forget their password (or lose it if they wrote it down). They are just going to never log in again. So it would be the same situation whether they were using passkeys or passwords. Passkeys were not meant to ‘solve’ this issue. There is no technical solution for the issue of a user not having the basic ability to use the ‘forgot password’ email flow. On the other hand, we need to have an account recovery mechanism for the vast majority of users who can use the email flow.