Passkey technology is elegant, but it's most definitely not usable security(arstechnica.com)
arstechnica.com
Passkey technology is elegant, but it's most definitely not usable security
https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/
381 comments
> With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account
And from this account you may be locked out for various reasons anytime, as it happened to countless persons previously, violating exotic or even understandable rules, or just been in the crossfire of some galactic corporate incompetence (some f'd up), but this way you'd be locking yourself out of everything especially if you were that user in the vacuum, exposing yourself to the mercy of a single organization with changing managemenet and incentives as the wind turns in a city's dense downtown.
And from this account you may be locked out for various reasons anytime, as it happened to countless persons previously, violating exotic or even understandable rules, or just been in the crossfire of some galactic corporate incompetence (some f'd up), but this way you'd be locking yourself out of everything especially if you were that user in the vacuum, exposing yourself to the mercy of a single organization with changing managemenet and incentives as the wind turns in a city's dense downtown.
>exposing yourself to the mercy of a single organization
The nice thing about passkey is that unlike password, you can have multiple per account.
So you can register a passkey from 1password to website A, and also register a passkey from Apple keychain to website A, and also register a passkey from Google account to website A, and also register a passkey from yubikey to website A, so even if you are locked out from one of your accounts, you still have several other ways to log into your account at website A.
And _if_ your, say, Apple keychain is compromised, you can just revoke the passkeys from your Apple keychain from all the websites (yes it's tedious, but it's doable).
The nice thing about passkey is that unlike password, you can have multiple per account.
So you can register a passkey from 1password to website A, and also register a passkey from Apple keychain to website A, and also register a passkey from Google account to website A, and also register a passkey from yubikey to website A, so even if you are locked out from one of your accounts, you still have several other ways to log into your account at website A.
And _if_ your, say, Apple keychain is compromised, you can just revoke the passkeys from your Apple keychain from all the websites (yes it's tedious, but it's doable).
Having to have multiple passkeys per site to circumvent vendor identity lock-in is one of the main problems with passkeys.
I'd be so easy if this proposal were implemented: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... one could always register one or more additional keys without having access to them.
A door can be kicked in, a safe can be drilled, a password can be reset. But these keys (whether a phone or a Yubikey) to your digital life are irreplaceable if they're all lost. We've never been in this situation before.
The problem with any solution relying on a couple of physical devices as the sole access to your digital life is that the management and protection of those objects becomes one of the most important things in your life. These keys are supposed to give perfect security so by design making "software" copies brings that security to the level of passwords. But losing them kills your digital life.
You have two keys in the house and you have a fire or severe natural disaster? There's no reset for them and you just piled a tragedy on top of another. You want to restore them from a backup? You probably need the keys to begin with. People need one on them at all times, one at home, one or two in some other safe far away location but to still trust that they won't be misused there.
That's all people hear when they look into passkeys. "One more key" is not enough for most people, tech savvy or not.
The problem with any solution relying on a couple of physical devices as the sole access to your digital life is that the management and protection of those objects becomes one of the most important things in your life. These keys are supposed to give perfect security so by design making "software" copies brings that security to the level of passwords. But losing them kills your digital life.
You have two keys in the house and you have a fire or severe natural disaster? There's no reset for them and you just piled a tragedy on top of another. You want to restore them from a backup? You probably need the keys to begin with. People need one on them at all times, one at home, one or two in some other safe far away location but to still trust that they won't be misused there.
That's all people hear when they look into passkeys. "One more key" is not enough for most people, tech savvy or not.
Even if it's possible technically, I don't think it's very practical, as UX is very heavily directed towards a single passkey provider. I can imagine doing this for one or two most important websites, but not for each of dozens (hundreds?) websites users have registeration on.
It's not actually all that bad. I went through today and added passkeys for all the sites I use that support them, and for most it went like this.
1. I login to the site using my password, supplied by my password manager (1Password).
2. I go to the site's security settings and find their passkey settings. I invoke their "add a passkey" function.
3. If I'm on my Mac, using Chrome, Firefox, or Safari, I get a dialog showing me the site and the user name and asking if I want to save a passkey in my 1Password.
There is a security key icon on the dialog that I can click if I want to save the passkey elsewhere. That replaces the 1Password dialog with one offering to save a passkey in my iCloud keychain for use on all my Apple devices.
That dialog has an "other options" link which brings up another dialog that adds options to use an external security key or to save a passkey on an iPhone, iPad, or Android device with a camera. The latter option will show a QR code that can be scanned on that other device.
I save the passkey in either 1Password or my iCloud keychain.
If I'm on my iPad using Safari it is similar, except the first dialog shows both 1Password and iCloud as storage destinations, with radio buttons to pick between them.
4. Repeat step #3 once, storing a passkey in whichever of 1Password and iCloud keychain that I didn't pick the first time through.
Some sites let you give the passkeys names to make them easier to remember so there might be typing a name in there somewhere.
All in all, it is only a few seconds to add a passkey after pressing the "add a passkey" button on a site, so adding two is no big deal.
1. I login to the site using my password, supplied by my password manager (1Password).
2. I go to the site's security settings and find their passkey settings. I invoke their "add a passkey" function.
3. If I'm on my Mac, using Chrome, Firefox, or Safari, I get a dialog showing me the site and the user name and asking if I want to save a passkey in my 1Password.
There is a security key icon on the dialog that I can click if I want to save the passkey elsewhere. That replaces the 1Password dialog with one offering to save a passkey in my iCloud keychain for use on all my Apple devices.
That dialog has an "other options" link which brings up another dialog that adds options to use an external security key or to save a passkey on an iPhone, iPad, or Android device with a camera. The latter option will show a QR code that can be scanned on that other device.
I save the passkey in either 1Password or my iCloud keychain.
If I'm on my iPad using Safari it is similar, except the first dialog shows both 1Password and iCloud as storage destinations, with radio buttons to pick between them.
4. Repeat step #3 once, storing a passkey in whichever of 1Password and iCloud keychain that I didn't pick the first time through.
Some sites let you give the passkeys names to make them easier to remember so there might be typing a name in there somewhere.
All in all, it is only a few seconds to add a passkey after pressing the "add a passkey" button on a site, so adding two is no big deal.
I currently have over 700 credentials in 1Password. Consider me not interested for anything that takes any decent amount of time.
I really like the idea of passkeys but I think most people forgot that security and convenience are not working well together, and passkeys attempt to solve this problem.
Passwords have their own issues but they are so easy to transport to multiple stores, meaning loosing access is going to be hard(er).
And as long as there's going to be a single-point-of-failure (being it Apple, Google, 1Password or whoever stores your passkeys) without any _easy_ way to retrieve your passkeys again I'm advising against it.
With passwords, I don't care loosing access to my iCloud/1Password/whatever. A somewhat recent list of all passwords are stored in a safe place, printed out on paper. AFAIK this isn't easily doable with passkeys.
I really like the idea of passkeys but I think most people forgot that security and convenience are not working well together, and passkeys attempt to solve this problem.
Passwords have their own issues but they are so easy to transport to multiple stores, meaning loosing access is going to be hard(er).
And as long as there's going to be a single-point-of-failure (being it Apple, Google, 1Password or whoever stores your passkeys) without any _easy_ way to retrieve your passkeys again I'm advising against it.
With passwords, I don't care loosing access to my iCloud/1Password/whatever. A somewhat recent list of all passwords are stored in a safe place, printed out on paper. AFAIK this isn't easily doable with passkeys.
You can still benefit from adding passkeys to some sites. It will often be a little faster and/or fewer clicks than using a password, especially at sites where you have to enter a TOTP code.
For example at Github signing in with a passkey from the sign in page is two clicks. Click on "Sign in with a passkey", a dialog pops up from the browser showing the passkey it will use by default, and I click "Sign in".
With a password it is a click to have 1Password fill my email and password, a click to submit (which could be eliminated if I had autosubmit enabled in 1Password), and then it asks for a TOTP code. After the code is entered it is a click to complete the sign in.
Github's TOTP entry form is well coded, so if 1Password has the TOTP key it will automatically fill it. If you don't keep TOTP keys in 1Password you'll have to open your authenticator app and copy the code.
Considering that it only takes a few seconds to add a passkey for Github to 1Password, you'll make up the time that takes after just a few logins.
For example at Github signing in with a passkey from the sign in page is two clicks. Click on "Sign in with a passkey", a dialog pops up from the browser showing the passkey it will use by default, and I click "Sign in".
With a password it is a click to have 1Password fill my email and password, a click to submit (which could be eliminated if I had autosubmit enabled in 1Password), and then it asks for a TOTP code. After the code is entered it is a click to complete the sign in.
Github's TOTP entry form is well coded, so if 1Password has the TOTP key it will automatically fill it. If you don't keep TOTP keys in 1Password you'll have to open your authenticator app and copy the code.
Considering that it only takes a few seconds to add a passkey for Github to 1Password, you'll make up the time that takes after just a few logins.
I'm not sure what UX you are talking about, the majority of the websites supporting u2f/passkey have UX to manage your u2f keys/passkeys. (the only exception I can think of is early Twitter when it first implemented u2f, and at that point it only allow you to add a single u2f key, but even Twitter fixed that later and supports multiple keys now).
And (this is probably not emphasized enough) you really should never only use a single u2f key/passkey for a website, that's the recipe to get you locked out when you can't find your u2f key/get locked out of the provider of your passkey. I have at least 2 yubikeys on my keychain all the time (one for usb-a and one for usb-c), plus one for each of my computers, and passkeys from 1password, google, etc.. And whenever I add u2f keys/passkeys to a website I add all/most of them.
And (this is probably not emphasized enough) you really should never only use a single u2f key/passkey for a website, that's the recipe to get you locked out when you can't find your u2f key/get locked out of the provider of your passkey. I have at least 2 yubikeys on my keychain all the time (one for usb-a and one for usb-c), plus one for each of my computers, and passkeys from 1password, google, etc.. And whenever I add u2f keys/passkeys to a website I add all/most of them.
...and you just described why this is not ready for prime time. Managing a number of physical devices tied to completely opaque secrets stored by unclear providers in places you never see, with hidden agendas promoting their locked-in solution over all others and complicating everything out of one ecosystem.
Most standard users will either mess up royally or run away scared. Damn, I've been on this field for 30 years, I've been using 4 OSs, 5 different browsers and devices from every ecosystem, and I still find this whole thing too much of a hassle.
And yes, I do have a backup passkey. Even though I had to convince my skip-level that it made sense. I just find it all too complex to adopt it broadly.
Most standard users will either mess up royally or run away scared. Damn, I've been on this field for 30 years, I've been using 4 OSs, 5 different browsers and devices from every ecosystem, and I still find this whole thing too much of a hassle.
And yes, I do have a backup passkey. Even though I had to convince my skip-level that it made sense. I just find it all too complex to adopt it broadly.
if I am reading right, any time you set up passkeys on a web site, you add half-a-dozen passkeys from various services? Yeah, this sounds totally impractical to me.
Have you considered stopping using passkeys and using strong passwords stored in password manager instead? You will have approximately same level of security:
- Either way, if one site is compromised other sites are not affected (because password managers have site-per-password)
- Either way, you will be phishing-protected (because password managers autofill based on host name, and you are smart enough not to override it)
- Either way, it'll be game over if you get a malware on your computer (because it will steal your passkey out of 1password)
... but your UX for new website would be dramatically simpler.
Have you considered stopping using passkeys and using strong passwords stored in password manager instead? You will have approximately same level of security:
- Either way, if one site is compromised other sites are not affected (because password managers have site-per-password)
- Either way, you will be phishing-protected (because password managers autofill based on host name, and you are smart enough not to override it)
- Either way, it'll be game over if you get a malware on your computer (because it will steal your passkey out of 1password)
... but your UX for new website would be dramatically simpler.
It's not much of a hassle. I'll add at least two when I want to start using a passkeys for a site. So maybe add a passkeys to the phone and to my keychain device. Then, next time I use the service on my laptop, I'll sign in with either my phone or keyring (whatever happens to be closer) and make one there. Then next time I want to use the service on my desktop I'll sign in with whatever I've got nearby and add my desktop and the token in my desk drawer. And maybe my password manager also has a passkeys, added somewhere in there.
It's not like every time I sign up for a new site I have to drop everything right at that instant and go add a passkey to every single device I own.
It's not like every time I sign up for a new site I have to drop everything right at that instant and go add a passkey to every single device I own.
Those websites are unimportant enough to just use normal passwords.
> And _if_ your, say, Apple keychain is compromised, you can just revoke the passkeys from your Apple keychain from all the websites (yes it's tedious, but it's doable).
without the key?
without the key?
Without a standard automatable way of doing this, it doesn't happen in practice, even assuming people implement it competently enough to allow multiple passcodes (TOTP codes, for example, are often only one per account, which is similarly annoying for maintaining a revocable backup)
> The nice thing about passkey is that unlike password, you can have multiple per account.
I would charitably estimate that of the sites currently supporting Passkey, the ones that support multiple passkeys are in the single digit percentage. So, practically, you can't.
I would charitably estimate that of the sites currently supporting Passkey, the ones that support multiple passkeys are in the single digit percentage. So, practically, you can't.
As someone who actually uses them in a lot of places, the number of sites I know that only allows a single passkey is one: PayPal. What other sites do you know only allow a single one?
PayPal allows multiple passkeys. I just added passkeys there today and had no trouble making two.
I have a vague recollection of running into some trouble when I tried to add passkeys to an account in their sandbox (sandbox.paypal.com) but don't remember what it was. I realized I don't need any of my sandbox accounts any more and deleted them all from my password manager rather than try to solve the problems. :-)
I have a vague recollection of running into some trouble when I tried to add passkeys to an account in their sandbox (sandbox.paypal.com) but don't remember what it was. I realized I don't need any of my sandbox accounts any more and deleted them all from my password manager rather than try to solve the problems. :-)
They do now? That's good to hear. It's been probably close to a year since the last time I checked. Thanks for the update on that.
So then that really makes me wonder what all those other sites these people are using which do only allow a single passkey.
So then that really makes me wonder what all those other sites these people are using which do only allow a single passkey.
I haven't run across any single key sites.
PayPal's handling of multiple passkeys is kind of annoying. I didn't see any way to change the default labels it gives them, which appear to be simply the OS and browser names. So both of my passkeys are labeled "macOS Chrome".
Clicking on them tells when they were created but the resolution is only to the day.
If somehow my private key for one of the them leaked and I wanted to delete the public key I wouldn't know which to delete.
Some sites label the passkeys "1Password" and something like "Apple iCloud" which works a lot better.
I too first experimented with passkeys about a year ago, and then largely ignored them until this discussion prompted me to have another go.
A year ago I found them almost unusable. I had trouble getting browsers to recognize a passkey was available for a site, and I had trouble getting browsers on my Mac to use passkeys from the Apple keychain on my Mac. They would often put up a QR code for me to scan on my phone to use the passkey from the phone--and that was also not very reliable.
Now I'm hitting almost no problems.
There are still some settings annoyance with some sites. At PayPal for instance it asks for my TOTP code even when logging in with a passkey. There is no option to turn off TOTP for passkeys but leave it on for passwords.
PayPal's handling of multiple passkeys is kind of annoying. I didn't see any way to change the default labels it gives them, which appear to be simply the OS and browser names. So both of my passkeys are labeled "macOS Chrome".
Clicking on them tells when they were created but the resolution is only to the day.
If somehow my private key for one of the them leaked and I wanted to delete the public key I wouldn't know which to delete.
Some sites label the passkeys "1Password" and something like "Apple iCloud" which works a lot better.
I too first experimented with passkeys about a year ago, and then largely ignored them until this discussion prompted me to have another go.
A year ago I found them almost unusable. I had trouble getting browsers to recognize a passkey was available for a site, and I had trouble getting browsers on my Mac to use passkeys from the Apple keychain on my Mac. They would often put up a QR code for me to scan on my phone to use the passkey from the phone--and that was also not very reliable.
Now I'm hitting almost no problems.
There are still some settings annoyance with some sites. At PayPal for instance it asks for my TOTP code even when logging in with a passkey. There is no option to turn off TOTP for passkeys but leave it on for passwords.
Yeah, sites should ideally ask for a label at passkey creation with a decent autogenerated one.
[deleted]
Ha, tell that to Apple. Last time I logged in to their App Connect it said that passkey can only be used from iOS or MacOS device.
At one point, a streamer on Youtube asked his audience something like "Spam F's in chat [to signal that you like this thing I just did]"
Hundreds of users got banned by Youtube for spamming.
But they didn't get banned from "Youtube". They got banned from "Google". They lost access to their Gmail, and to their Android login, and every other Google service, meaning they lost their phone text verification system for every other login, and quite possibly their password manager.
Hundreds of identities were stolen and set on fire by an overly aggressive approach to spam management.
I try to remember this failure mode in planning (or being unable to plan) the security of my online presence.
Then I incorporate Elon Musk's recent behavior and recognize that while the profit motive _generally_ constrains the behavior of these firms, it's by no means assured.
For basic social welfare, either this identity stuff needs to be heavily regulated or all of these big companies need to be broken up.
Hundreds of users got banned by Youtube for spamming.
But they didn't get banned from "Youtube". They got banned from "Google". They lost access to their Gmail, and to their Android login, and every other Google service, meaning they lost their phone text verification system for every other login, and quite possibly their password manager.
Hundreds of identities were stolen and set on fire by an overly aggressive approach to spam management.
I try to remember this failure mode in planning (or being unable to plan) the security of my online presence.
Then I incorporate Elon Musk's recent behavior and recognize that while the profit motive _generally_ constrains the behavior of these firms, it's by no means assured.
For basic social welfare, either this identity stuff needs to be heavily regulated or all of these big companies need to be broken up.
I couldn't find any other source for that anecdote, but did find plenty of other reports:
Terraria on Stadia cancelled after developer's Google account gets locked https://news.ycombinator.com/item?id=26061935
Google users locked out after 15 years' use https://news.ycombinator.com/item?id=24965432
I got locked out of my Google account for a month https://news.ycombinator.com/item?id=15989146
Tell HN: Need help, locked out of Google account with 10 years of personal data https://news.ycombinator.com/item?id=42350245
Android user locked out of Google after moving cities https://news.ycombinator.com/item?id=13004369
Ask HN: I'm a small business and Google locked me out https://news.ycombinator.com/item?id=22705122
Ask HN: Locked out of Google services with no recourse or explanation https://news.ycombinator.com/item?id=17428707
ASK HN: Google account disabled. Oh what to do? https://news.ycombinator.com/item?id=350968
Ask HN: Google just kicked me out of my account, no option to verify https://news.ycombinator.com/item?id=24709282
Man locked out of Google Drive and loses 9 year old photos after SIM Swap attack https://news.ycombinator.com/item?id=41915523
Ask HN: Locked out of Google Aps email with no recourse - advice? https://news.ycombinator.com/item?id=9768593
When you get locked out of your Google account, what do you do? https://news.ycombinator.com/item?id=31070914
Terraria on Stadia cancelled after developer's Google account gets locked https://news.ycombinator.com/item?id=26061935
Google users locked out after 15 years' use https://news.ycombinator.com/item?id=24965432
I got locked out of my Google account for a month https://news.ycombinator.com/item?id=15989146
Tell HN: Need help, locked out of Google account with 10 years of personal data https://news.ycombinator.com/item?id=42350245
Android user locked out of Google after moving cities https://news.ycombinator.com/item?id=13004369
Ask HN: I'm a small business and Google locked me out https://news.ycombinator.com/item?id=22705122
Ask HN: Locked out of Google services with no recourse or explanation https://news.ycombinator.com/item?id=17428707
ASK HN: Google account disabled. Oh what to do? https://news.ycombinator.com/item?id=350968
Ask HN: Google just kicked me out of my account, no option to verify https://news.ycombinator.com/item?id=24709282
Man locked out of Google Drive and loses 9 year old photos after SIM Swap attack https://news.ycombinator.com/item?id=41915523
Ask HN: Locked out of Google Aps email with no recourse - advice? https://news.ycombinator.com/item?id=9768593
When you get locked out of your Google account, what do you do? https://news.ycombinator.com/item?id=31070914
Going from memory, the GP comment is from a Markiplier video where he created a "game" in which you choose what path to take.
On the release stream he was asking people to "vote" which path to take, and IIRC it was by writting blue ball emoji or red ball emoji.
People were banned and he took it personally. Contacted his internal youtube contacts and all. There should be videos about him talking of it.
On the release stream he was asking people to "vote" which path to take, and IIRC it was by writting blue ball emoji or red ball emoji.
People were banned and he took it personally. Contacted his internal youtube contacts and all. There should be videos about him talking of it.
Yes, I think that was the incident in question, thanks.
Thanks for taking the time to create this list up, will be linking this when passkeys are brought up.
This is the exact scenario that led me to register my own domain name and email address on it.
Just remember if you ever give up your domain, whoever purchases it will now have your email as root-of-trust to EVERY site you ever created an account with.
Also, it can be pricey. If you have a .com/.org it is cheap, but I have a .io and the price keeps doubling every few years.
Also, it can be risky: and there is a very real risk that .io will be (rightly) reclaimed by the country that owns it and either seize the domains are really jack up the prices even more.
Also, it can be pricey. If you have a .com/.org it is cheap, but I have a .io and the price keeps doubling every few years.
Also, it can be risky: and there is a very real risk that .io will be (rightly) reclaimed by the country that owns it and either seize the domains are really jack up the prices even more.
I use a .net domain that is automatically renewed via AWS and costs like $7/year.
Yeah I would suggest against using a ccTLD unless you have a strong connection to that country. Don't buy .io or .ai because they're trendy. Buy .com or .net or .dev or something else generic, or buy .co.uk if you live in the UK etc.
I have a .net which I register for 10 years at a time; and renew every 5-8 years in.
Don't you end up paying twice that way?
No? Your expiry just extends the number of years you add to the renewal.
That makes sense.
Even without malice or incompetence you will have false positives and false negatives. Then when you attempt to correct the mistake you will have false positives and false negatives again.
Should a false positive from the YouTube anti-spam algorithm accidentally temp-ban someone from commenting on YouTube for a week, or should it permanently and irrevocably destroy their online presence, possibly preventing them from logging into anything online: email, banking, government services, paying their mortgage? Because the whole problem is that we're in the universe where the latter happens.
I see now how it sounds that way but I'm not making excuses. It was to describe the puzzle without all the emotional luggage. You need a system that gets it wrong, corrects it self then gets the correction wrong with infinite recursion.
Instant judgement shooting from the hip without dialog or appeal is the dumbest way of doing things. Google isn't even trying.
Instant judgement shooting from the hip without dialog or appeal is the dumbest way of doing things. Google isn't even trying.
> Hundreds of users got banned by Youtube for spamming.
is there a source for this? googling just brought me back here
is there a source for this? googling just brought me back here
https://9to5google.com/2019/11/09/google-account-bans-youtub...
This article provides a good summary of events.
The short of it, is that a YouTuber was Livestreaming.
He asks viewers to spam certain emojis to select what path the streamer should take.
Google's automated system detected the spam, and banned google accounts.
This article provides a good summary of events.
The short of it, is that a YouTuber was Livestreaming.
He asks viewers to spam certain emojis to select what path the streamer should take.
Google's automated system detected the spam, and banned google accounts.
I’ve heard this story quite a few times but it’s always hearsay without anything concrete enough to even begin to verify. Given that one account of mine got perma-banned on YouTube (for violating the “impersonation rule” with a bunch of screen recordings set to private…) and it didn’t affect the rest of the account, I have to assume the story is fake.
https://9to5google.com/2019/11/09/google-account-bans-youtub...
It definitely was not fake. I saw plenty of uproar on the day it happened.
I remember a number of tech channels also started to post videos on how to de-google right after that.
It definitely was not fake. I saw plenty of uproar on the day it happened.
I remember a number of tech channels also started to post videos on how to de-google right after that.
Oh okay.
[deleted]
This legitimately terrifies me because it feels like a realistic eventual outcome — whether it’s via a careless automated system with no recourse or simply enshittification of an existing product due to leadership change.
I’m so entrenched in various platform ecosystems I’m not even sure how to claw my way out of it.
I’m so entrenched in various platform ecosystems I’m not even sure how to claw my way out of it.
I solve this by creating two passkeys for each account, for iOS and Chrome. This covers all the devices I might use to log in and there’s no single point of failure.
The fact that the problem is solvable by technically savvy people doesn’t stop it from being a problem for the general user.
To add an insanely unsatisfactory solution as well.
Even passwords are better. Seriously.
Even passwords are better. Seriously.
Many passkey-supporting sites only support a single passkey per account.
This feels like the biggest misstep that may impede the success of passkeys to me. It's not that surprising, though, since it's pretty rare to find genuine support for multiple authentication factors of the same type already. You can usually only register one number for SMS, and/or one TOTP authenticator, etc. It seems like a lot of sites never really understood (or cared about) the benefits of MFA to the user and so can't be bothered to really understand passkeys either.
I keep hearing this but then the only example I'm given is PayPal and that AWS used to be this way. What big sites do you experience only allow a single passkey?
Yes, this definitely needs to be fixed!
Besides passkeys, some websites have alternative backup authentication, though, such as backup codes. However you do it, there should be an independent way to log in.
Besides passkeys, some websites have alternative backup authentication, though, such as backup codes. However you do it, there should be an independent way to log in.
I use a passkey on every site that supports it (say two dozen at this point). I have never encountered this.
Which is a serious flaw in the standard.
[deleted]
Which?
Paypal is one I've encountered.
Paypal, as far as I can tell, doesn't even (intentionally) support passkeys. They refer to all WebAuthN credentials as "security keys" and remind me to "plug it in and touch it now" etc.
I'm honestly already glad that they didn't make their annoying browser fingerprinting rigorous enough to also block authentications and aren't requiring attestation.
I'm honestly already glad that they didn't make their annoying browser fingerprinting rigorous enough to also block authentications and aren't requiring attestation.
Even google account's MFA allows back up codes, at least in the Enterprise accounts.
I get that this this is a way to do it in practical terms, but isn't that just like having to have two passwords for each site (outside the fact that passkeys are a bit more secure than passwords)? I thought one of the main points of passkeys was to reduce admin.
If you can do that, you also have enough tech savyness to use passwords securely.
The security of passwords doesn't just depend on users though.
https://haveibeenpwned.com/PwnedWebsites
https://haveibeenpwned.com/PwnedWebsites
2FA does not protect against a website getting hacked.
The problem that passkeys solve is not that of their user. It is that of the website that authenticates its users. With mere passwords, there is no way they can be sure that the user follows the required password hygiene. With passkeys, there is no way a user could set up something insecure.
Are we taling savvy users or regular users?
Regular users would not set up double passkeys, and would suffer vendor lock. They would be better off with password manager instead.
Savvy users know how to follow password hygiene, and have no need to have it enforced on them. So they don't need passkeys either, they would be better of with good password manager.
Regular users would not set up double passkeys, and would suffer vendor lock. They would be better off with password manager instead.
Savvy users know how to follow password hygiene, and have no need to have it enforced on them. So they don't need passkeys either, they would be better of with good password manager.
Exactly what I am saying. Users don't need passkeys. Auditors and other guys from the checkbox compliance department on the opposite side do, for "security posture".
That doesn't solve anything. You just have twice as many problems now.
What are you talking about? Redundancy is how you avoid getting locked out. Each passkey serves as a backup for the other one.
More generally, you should have two keys for any lock, so you can still get in if you lose one of them.
More generally, you should have two keys for any lock, so you can still get in if you lose one of them.
Setting up both Apple and Google passkeys solves:
* Lost access to your Google account, but still have access to your Apple account (or vice-versa)
* Apple device doesn't support Google passkeys, or vice-versa
But it multiplies the following downsides:
* Apple/Google account gets hacked, hacker gets all your 2FA credentials
* Snooping on your activity. Particularly Google, but Apple also have an advertising business.
* Setting up accounts on new sites is twice the hassle.
* Too complicated for the kind of folks who need the phishing protection passkeys provide.
* Lost access to your Google account, but still have access to your Apple account (or vice-versa)
* Apple device doesn't support Google passkeys, or vice-versa
But it multiplies the following downsides:
* Apple/Google account gets hacked, hacker gets all your 2FA credentials
* Snooping on your activity. Particularly Google, but Apple also have an advertising business.
* Setting up accounts on new sites is twice the hassle.
* Too complicated for the kind of folks who need the phishing protection passkeys provide.
> I solve this by creating two passkeys for each account, for iOS and Chrome. This covers all the devices I might use to log in and there’s no single point of failure.
This just seems to mean that, instead of being the whim of one corporation from being locked out of all your accounts, you're the whim of two corporations away. That's better, but I'd hardly call it solved.
This just seems to mean that, instead of being the whim of one corporation from being locked out of all your accounts, you're the whim of two corporations away. That's better, but I'd hardly call it solved.
“Google says no” is a threat model I’m concerned about, but it doesn’t seem particularly likely, so I’ll pick another passkey manager if it happens.
(If it ever happened, Gmail and Google Photos would be a bigger loss.)
(If it ever happened, Gmail and Google Photos would be a bigger loss.)
[deleted]
Does that mean you're locked into iOS and Chrome?
Using 1Password as your passkey backend seems like it would solve all the problems you're describing, except that passkeys are (for the time being, at least) locked in to 1Password [1]. It works on multiple OSes (as a native passkey backend on iOS, via browser extensions providing WebAuthN on all major OSes) and isn't tied to your Apple ID.
If you care a lot about exportable passkeys, Bitwarden (and Vaultwarden) can export them. Not sure if any other implementation can import them at the moment, but the data looks portable enough (i.e. it contains the ECDSA private key and all other client properties required).
[1] https://support.1password.com/save-use-passkeys/ mentions that "Passkeys saved in 1Password can’t be exported at this time."
If you care a lot about exportable passkeys, Bitwarden (and Vaultwarden) can export them. Not sure if any other implementation can import them at the moment, but the data looks portable enough (i.e. it contains the ECDSA private key and all other client properties required).
[1] https://support.1password.com/save-use-passkeys/ mentions that "Passkeys saved in 1Password can’t be exported at this time."
1P will support it in a standards-compliant way soon: https://blog.1password.com/fido-alliance-import-export-passk...
KeePassXC also supports export but not yet using the aforementioned standard: https://github.com/keepassxreboot/keepassxc/issues/11363
KeePassXC also supports export but not yet using the aforementioned standard: https://github.com/keepassxreboot/keepassxc/issues/11363
> 1P will support it in a standards-compliant way soon: https://blog.1password.com/fido-alliance-import-export-passk...
See then believe, in the current environment saying "soon" based on 1password submitting a draft is much too optimistic, given the big interests Google and Apple have in neutering this possibility.
See then believe, in the current environment saying "soon" based on 1password submitting a draft is much too optimistic, given the big interests Google and Apple have in neutering this possibility.
I’m not saying I’m against 1pass adding the ability to export passkeys from 1Pass, however, doesn’t this increase the possibility of your computer is compromised (say remote control) and now your passkey is exported / moved to a new device and hacker auths in via that new device? (versus with a hardware passkey which cant be exported electronically)
Same, I use bitwarden and it keeps all my passkeys in it and is available on all my devices.
>In some parallel universe, each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys). Instead of "many cooks" mentioned in the article, there is one standard.
Ignoring site support, this exists. It's called USB and yubikey.
Ignoring site support, this exists. It's called USB and yubikey.
Having a big dongle sticking out of your iPhones lighning port is completely impractical, compared to using the integrated TPM backed storage, unlocked by face-id. Yes there are smaller dongles but only for usb-c and i still don't want to fiddle with it when charging.
It's only a matter of time before desktops gain the same secure key storage as our phones do, add a hardware key to prove physical presence and then yubikeys are obsolete. The only future for yubikeys is for temporary transfer of keys under wrap between devices, where you don't want to use a cloud service for doing so.
While an open api with replaceable internals is a nice idea and one that enabled yubikeys in the first place, once this is integrated in the SoC and the OS, there will be little need for alternative storage backends. What's more pressing now is pluggable synchronization of secrets, for those who don't want their choice of cloud provider to be bound to their choice of OS, or for those who rather synchronize entirely offline through a yubikey.
It's only a matter of time before desktops gain the same secure key storage as our phones do, add a hardware key to prove physical presence and then yubikeys are obsolete. The only future for yubikeys is for temporary transfer of keys under wrap between devices, where you don't want to use a cloud service for doing so.
While an open api with replaceable internals is a nice idea and one that enabled yubikeys in the first place, once this is integrated in the SoC and the OS, there will be little need for alternative storage backends. What's more pressing now is pluggable synchronization of secrets, for those who don't want their choice of cloud provider to be bound to their choice of OS, or for those who rather synchronize entirely offline through a yubikey.
Was called a SIM card before that.
Both are smartcards. Yubikeys also happen to support the USB HID CTAP protocol, which is something unprivileged applications can usually talk to directly on most operating systems. Most other CTAP transports are just smartcard transports (APDUs over PC/SC or NFC). Yubikeys also have a PIV applet, which isn't used for your typical enterprise X.509 PKI, and an OpenPGP applet, which typically isn't used.
PIV, GnuPG, or PKCS#15 are probably better comparisons. SIM cards use symmetric cryptography, which means you can only authenticate yourself to a single entity.
> this exists. It's called USB and yubikey
An extra physical device is a non-starter for mass adoption.
An extra physical device is a non-starter for mass adoption.
[deleted]
”But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.”
Apple has recently addressed this. You can now create shared groups, and selectively assign passwords and passkeys to the groups. You could easily create a group with your two identities and move the credentials to that group.
https://support.apple.com/guide/iphone/share-passwords-iphe6...
Apple has recently addressed this. You can now create shared groups, and selectively assign passwords and passkeys to the groups. You could easily create a group with your two identities and move the credentials to that group.
https://support.apple.com/guide/iphone/share-passwords-iphe6...
Beware of the hidden catch here. The account that adds the credential to the group “owns” it. So if that account goes away for any reason so does the credential.
>But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs
You can't save your personal passkeys on your work phone and vice versa, but when logging in to a service on one device, you should be able use a passkey from the other device via Bluetooth by scanning a QR code.
You can't save your personal passkeys on your work phone and vice versa, but when logging in to a service on one device, you should be able use a passkey from the other device via Bluetooth by scanning a QR code.
An added challenge: Yubikey NFC doesn't work on iPad, only iPhone. USB operation also seems fraught. This has been so for 7+ years now. If Apple cannot get this to work with a closed ecosystem and the leading vendor, I think the technology is just not ready for mainstream.
Apple is actually doing a lot of work (largely) in the background with every OS update.
I was recently pleasantly surprised to be able to use my smartcard form factor FIDO authenticator on macOS using a CCID USB smartcard reader. Not exactly ergonomic on a laptop, but totally viable on a desktop or docking station setup with a permanently plugged in reader. Sometimes I really do miss that contactless card reader option that some Thinkpads offered...
I was recently pleasantly surprised to be able to use my smartcard form factor FIDO authenticator on macOS using a CCID USB smartcard reader. Not exactly ergonomic on a laptop, but totally viable on a desktop or docking station setup with a permanently plugged in reader. Sometimes I really do miss that contactless card reader option that some Thinkpads offered...
Yubikeys work on iPad and iPhone via USB perfectly fine now. I do it quite often.
Woah, you are correct. My YubiKey 5C now works with my iPad M4! When did they fix that??
Edit: Looks like it was iPadOS 18.2 released on December 11th.
Edit: Looks like it was iPadOS 18.2 released on December 11th.
I think they added better hardware key support at an OS level a little over two years ago. They needed all the web authn stuff for passkeys anyways, so I bet it was a necessity prerequisite.
I just got the new M4 iPad like two months ago, and my YubiKeys absolutely did not work, no matter what I tried. There are articles on apple.com and yubikey.com that explain that USB-C YubiKeys will not work with USB-C iPads because Apple's USB-C implementation isn't sending the timing info (or something like that) that the YubiKey needs to function. People were buying Lightening YubiKey and connecting them to Apple's Lightening to USB-C "camera adapter" to work around this.
I decided to double-check my YubiKeys before I responded to your post and (!!!) they work now! This is huge!
I decided to double-check my YubiKeys before I responded to your post and (!!!) they work now! This is huge!
Good to know, thanks! But I might not have the other device on me at all times.
FIDO keys are tiny e.g. yubikey 5c
If anything, this achieves the opposite of making sure I always have mine on me.
Dedicated, external hardware authenticators are great for logging in to very high value accounts or password managers, but arguably they're not really viable for 99% of users and use cases on a day-to-day basis.
Dedicated, external hardware authenticators are great for logging in to very high value accounts or password managers, but arguably they're not really viable for 99% of users and use cases on a day-to-day basis.
I don't agree at all. It's on my keychain, next to my keys, a nice symmetry. When I need to login I hold it to the back of my phone for half a second. It's incredibly easy and would be even easier if it weren't for the UX presented by iOS, Android, and Windows where they try to be the provider. Android has gotten a bit better. Windows is the worst about it afaict.
Different people, different preferences.
I don't like having to fetch my keys when I'm at home at all, which is where I do most of my authentications. I'd have to get up, walk to where I usually keep them, walk to my computer with them to authenticate, and then either walk back or forget the keys somewhere in the house and have to search for them when leaving (or detach the authenticator from the keychain and then not have it on me when I'm leaving).
That's why I don't like using USB authenticators on a regular basis.
I don't like having to fetch my keys when I'm at home at all, which is where I do most of my authentications. I'd have to get up, walk to where I usually keep them, walk to my computer with them to authenticate, and then either walk back or forget the keys somewhere in the house and have to search for them when leaving (or detach the authenticator from the keychain and then not have it on me when I'm leaving).
That's why I don't like using USB authenticators on a regular basis.
It’s recommended to have at least two anyway, to still have access to your accounts in case one is lost. That means you can keep one key at your desktop and you’d only need to go up to get your keys when adding them to an account.
Having two in the same house is a pretty bad compromise. Ideally you'll want one of them to be physically somewhat distant (in case of a fire etc.), which makes things even less ergonomic.
I think that we should consider passing a law that a vendor may non disable “log in with” and supporting functionality like password recovery, for a user account for some lengthy period of time after involuntary termination of the user.
But I think that the bigger issue is that I don’t think that large corporations should be allowed to disassociate with their users except in the case where criminal activity against that company is involved. This is especially important now that all the vendors want ecosystem lock-in AND have ToS that allow them to cancel pretty much arbitrarily.
But I think that the bigger issue is that I don’t think that large corporations should be allowed to disassociate with their users except in the case where criminal activity against that company is involved. This is especially important now that all the vendors want ecosystem lock-in AND have ToS that allow them to cancel pretty much arbitrarily.
Agreed, and some kind of appeals process/ external arbitrator, if your account is terminated due to terms of service or automation.
Pretty sure 1password can store and use passkeys.
It does, but 1password forces you to use the browser extension in order to manage passkeys.
I still don't trust browser extensions. I'm probably being irrational, but it is hard to find good sec info on how "safe" extensions really are.
I still don't trust browser extensions. I'm probably being irrational, but it is hard to find good sec info on how "safe" extensions really are.
If you're copy-pasting passwords from 1password into your browser you're making yourself vulnerable to phishing. The browser extension's autofill will at least check the domain name and prevent that.
Somewhat. Lots of sites log you in via a different domain.
That’s the domain you’d have saved, then. You can also save multiple domains on a credential.
I know about the issue and still experience it. Sometimes these things also change over time. Of course, it still helps to use the browser extension!
That does get me every now and then. “Why has this stopped autofilling…”
It certainly can.
until the time comes that it's used for spammers and everyone requires providers from a list that only included apple and Google.
y'all trying very hard to not see where this will go.
y'all trying very hard to not see where this will go.
This would be possible via attestation, but both Apple and Google removed that feature when they replaced their respective device-bound authenticator implementations with cloud-synchronizing ones. (Google technically still allows creating device-bound ones and supports attestation in that case, but that's arguably a niche use case and not what people are talking about when they say "passkeys".)
> I already have a universal solution for credentials: 1password, which is cross-platform.
You can store passkeys in 1password so they work everywhere.
You can store passkeys in 1password so they work everywhere.
The article is 80% about friction and confusion in trying that solution - from confusing prompts and endless questions designed to wrestle control over to local ecosystem, to use cases that just don't work with external vendor as opposed to native platform owner :-(
Which use cases don't work with external implementations, but do with the first-party one? I have yet to encounter one on iOS and macOS.
https://github.com/keepassxreboot/keepassxc/issues/10374 Passkeys not working on certain sites
I suspect 1password also has at least a few sites that need special handling
I suspect 1password also has at least a few sites that need special handling
But 1password forces you to install the browser extension to do this.
Honest question, this isn't supposed to be a burn in any sense. But isn't it contradictory to want to know how and where your credentials are stored and use any credential management solution that isn't opensource and selfhosteable?
Fair enough, but I believe there is a spectrum between "I don't want to know things, let them just work" and "self-host and manage an application for storing the most sensitive type of information".
1Password is neither opensource nor self-hostable, and it stores data in the proprietary cloud (at least exports are easy). But I understand that and accept it.
If I get a Macbook, an Android phone, and a Windows PC (a very popular combination of devices, btw), I honestly don't have energy to investigate how to inter-operate their passkey solutions. From the get go, I assume it's gonna be either impossible, or very hacky and fragile. Maybe I'm wrong, but last time I checked I simply walked away thinking "nope, no passkeys for me".
1Password is neither opensource nor self-hostable, and it stores data in the proprietary cloud (at least exports are easy). But I understand that and accept it.
If I get a Macbook, an Android phone, and a Windows PC (a very popular combination of devices, btw), I honestly don't have energy to investigate how to inter-operate their passkey solutions. From the get go, I assume it's gonna be either impossible, or very hacky and fragile. Maybe I'm wrong, but last time I checked I simply walked away thinking "nope, no passkeys for me".
1Password itself has native passkey support. I don't have experience with it on mobile, but on desktop browsers their extension overrides the build-in passkey support to use/store passkeys from/in 1Password (with a button to fall back to the built-in implementation for its storage, hardware tokens, QR code to use/store a passkey from/on a smartphone, etc).
Looks like on iOS it integrates with the native passkey support (so is usable anywhere native passkeys are supported). 1Password on Android looks to have similar integration, but only for apps at this stage (not websites, due to an Android limitation). So still a little while to go yet for "it just works" across all platforms.
> With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer.
iCloud Keychain/Passwords works on macOS and Windows, and there are extensions for Chrome and Edge. I don't know whether it works with passkeys though.
> But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.
As I understand it, Apple's BYOD support allows you to have a managed/corporate Apple ID and a personal Apple ID on the same device. You can also add a managed Apple ID to a personal device like an iPhone; on iOS (and possibly macOS?) it isolates the data between them so that corporate apps can't access personal data and vice-versa.
I believe it's possible to have multiple accounts with separate Apple IDs, and I think it is possible to add "secondary" Apple IDs to a single account, but I don't have experience with this.
iCloud Keychain/Passwords works on macOS and Windows, and there are extensions for Chrome and Edge. I don't know whether it works with passkeys though.
> But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.
As I understand it, Apple's BYOD support allows you to have a managed/corporate Apple ID and a personal Apple ID on the same device. You can also add a managed Apple ID to a personal device like an iPhone; on iOS (and possibly macOS?) it isolates the data between them so that corporate apps can't access personal data and vice-versa.
I believe it's possible to have multiple accounts with separate Apple IDs, and I think it is possible to add "secondary" Apple IDs to a single account, but I don't have experience with this.
I don’t know about 1password, but proton pass supports passkeys, on both iOS, Safari & Chrome (and probably others).
I use proton pass and have the same issues as the author. Whenever macos/ios is in the mood it lets me use it to store passkeys, else it is an endless maze of bugs and confusion. Proton pass supports passkeys but the OS does not always let it communicate with the website.
Any chance that this is actually due to websites requesting weird WebAuthN credential parameters (e.g. enforcing attestation, which software implementations by definition will not be able to support) or using the legacy U2F API? In my experience that's usually the culprit.
No idea. I do not have the technical knowledge neither the time to check sth like that. I am totally clueless even as to where and how exactly passkeys are stored in my computer. For me they just work until they don’t. It does not really help in trusting them as password replacement.
I moved away from 1P some time ago due to their move to a subscription model. After trying other solutions and having high hopes for Apple finally shipping a passwords app I finally decided to move back this year.
It's costly but excellent. I have several accounts shared with my wife and was getting caught up in the passkey problems you mentioned. Even though 1P handling OTP is not really 2FA it's very convenient and still more secure than no OTP. I also don't always want to have to have my phone on me.
On top of that I like knowing that if I change my mind at some point I can export my credentials. Moving my iCloud keychain creds was an eye-opener: it felt purposefully painful. You can do it but much of the metadata is missing or lost in the process, with the titles being the URLs. Yuck.
It's costly but excellent. I have several accounts shared with my wife and was getting caught up in the passkey problems you mentioned. Even though 1P handling OTP is not really 2FA it's very convenient and still more secure than no OTP. I also don't always want to have to have my phone on me.
On top of that I like knowing that if I change my mind at some point I can export my credentials. Moving my iCloud keychain creds was an eye-opener: it felt purposefully painful. You can do it but much of the metadata is missing or lost in the process, with the titles being the URLs. Yuck.
Switching from 1p to icloud makes sense, but there's a decent chunk that isnt in the apple ecosystem. I'm keeping 1p for now, I'd even argue that the price is pretty good, especially for families.
To be clear I never used iCloud/keychain exclusively, but my wife did and I performed the migration from that to 1P.
I prefer to pay for something as important as a password manager. It's like some people get excited about all-you-can-eat sushi: sorry, but raw fish isn't something I want to go super-cheap with.
Have you tried bitwarden?
Yep that's mainly what I used. I trust it and it has a good feature set but the UX is just not up to snuff imo. I could get by with it but no way was I going to roll it out to my less techy family members.
1P is just much easier to use and more polished.
1P is just much easier to use and more polished.
I've heard others say similar things.
Bitwarden was a big UX upgrade for me coming from keepass.
I haven't tried 1P. What do you prefer about?
Bitwarden was a big UX upgrade for me coming from keepass.
I haven't tried 1P. What do you prefer about?
> I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc.
There is a draft standard in the works for export/import:
* https://fidoalliance.org/specifications-credential-exchange-...
There is a draft standard in the works for export/import:
* https://fidoalliance.org/specifications-credential-exchange-...
[deleted]
> But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.
By design. This is what caused the ZenDesk, Atlassian, Disney and Sony hacks.
By design. This is what caused the ZenDesk, Atlassian, Disney and Sony hacks.
> their single, universal, transferrable set of security credentials (like passkeys)
That's an awful idea. Normal people already have a nightmare of a time with getting locked out of accounts, and now you want their entire lives to depend on a single hardware fob that can get lost?
That's an awful idea. Normal people already have a nightmare of a time with getting locked out of accounts, and now you want their entire lives to depend on a single hardware fob that can get lost?
Passkeys are the ideal identity management solution for spherical users in a vacuum
That was called "U2F", but we made it "better" with PassKeys!
> is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys)
Wow, that will immediately become a prime target for hackers / phishers.
Wow, that will immediately become a prime target for hackers / phishers.
So?
Then we're getting to a point where the proposed law weakens passkeys to the point where they are much ado about nothing.
each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys)
Indeed and that law would provide overrides for the state. And which state, you might ask? All of them? The state where the device is manufactured? Hmm...
Indeed and that law would provide overrides for the state. And which state, you might ask? All of them? The state where the device is manufactured? Hmm...
The article author skirts around the key true observation here, which is that passkeys were a great idea until cloud vendors waged war on hardware keys.
The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise.
The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article.
The ideal future state is:
* the provider for newly registered credentials would be a browser setting
* the setting would come configured to use the OS vendor out of the box
* installing a password manager providing passkeys would prompt to change the setting to use the password manager instead
* one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option
* there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever
In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience.
The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.
The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise.
The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article.
The ideal future state is:
* the provider for newly registered credentials would be a browser setting
* the setting would come configured to use the OS vendor out of the box
* installing a password manager providing passkeys would prompt to change the setting to use the password manager instead
* one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option
* there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever
In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience.
The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.
> passkeys were a great idea until cloud vendors waged war on hardware keys.
> The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
This was never a great idea, it was totally unworkable for nearly everyone. Physical keys work because locksmiths exist, keys can be copied, and users get to choose when they lock the door/box/whatever. And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.
Hardware keys as envisioned here cannot be copied without registering the copy separately with each and every service, have no equivalent of locksmiths besides "store these 10 recovery codes somewhere safe" (also unworkable as a solution), and between session timeouts and multiple devices users are regularly unable to predict when and where they will need to create a new session.
Hardware keys were designed for a spherical humanity, not for the humanity that has to deal with ADHD, dementia, babies, kids, fires, floods, and a host of other failure modes. OS keys inherit many but not all of the flaws of hardware keys, but at least they don't rely on a human being responsible!
> The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
This was never a great idea, it was totally unworkable for nearly everyone. Physical keys work because locksmiths exist, keys can be copied, and users get to choose when they lock the door/box/whatever. And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.
Hardware keys as envisioned here cannot be copied without registering the copy separately with each and every service, have no equivalent of locksmiths besides "store these 10 recovery codes somewhere safe" (also unworkable as a solution), and between session timeouts and multiple devices users are regularly unable to predict when and where they will need to create a new session.
Hardware keys were designed for a spherical humanity, not for the humanity that has to deal with ADHD, dementia, babies, kids, fires, floods, and a host of other failure modes. OS keys inherit many but not all of the flaws of hardware keys, but at least they don't rely on a human being responsible!
> And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.
I would be careful with the use of "suboptimal" here. PIN codes or mobile apps are possibly more convenient to some people, not necessarily more secure (a PIN can leak, a smartphone can be hacked).
I would argue that hardware keys are optimal in the use-case they solve. It's just that not everybody wants to solve this use-case. And that's okay: passkeys should allow users to choose.
I would be careful with the use of "suboptimal" here. PIN codes or mobile apps are possibly more convenient to some people, not necessarily more secure (a PIN can leak, a smartphone can be hacked).
I would argue that hardware keys are optimal in the use-case they solve. It's just that not everybody wants to solve this use-case. And that's okay: passkeys should allow users to choose.
Yea, the physical key is, to me at least, one of the top human inventions.
Ubiquitous, cheap, convenient, and provides sufficient security. My little brass key never needs charging, never refuses to open the door because I didn't apply the latest over-the-air update, doesn't phone home to an advertising firm to track every time I open and close a door.
I can make as many copies as I like and give them to friends and family in case I lose mine. There are some scenarios where it might be nice to have a smart lock, but for me at least, they are so few and far between that I'll stick with this tiny bit of metal.
Ubiquitous, cheap, convenient, and provides sufficient security. My little brass key never needs charging, never refuses to open the door because I didn't apply the latest over-the-air update, doesn't phone home to an advertising firm to track every time I open and close a door.
I can make as many copies as I like and give them to friends and family in case I lose mine. There are some scenarios where it might be nice to have a smart lock, but for me at least, they are so few and far between that I'll stick with this tiny bit of metal.
I completely agree. I also call "citation needed" on physical keys being replaced.
This is valid: use case matters. But almost no one has a use case for which hardware keys are optimal.
If you live in an area where you don't have bars on your windows, you don't gain more security from using a physical key over a PIN or app. (Even if you do have bars, the physical key is likely still suboptimal).
If you're a regular user of the kind of application where anyone ever thought passwords were a valid authentication solution, you don't benefit from a hardware key.
And it's not just a question of more security than necessary: using a security mechanism that is overkill for your needs can actually leave you with lower total security, because you'll end up doing things to make your life more convenient that are worse than what you'd have done with a weaker mechanism (like in the physical case leaving the door unlocked to avoid locking yourself out).
If you live in an area where you don't have bars on your windows, you don't gain more security from using a physical key over a PIN or app. (Even if you do have bars, the physical key is likely still suboptimal).
If you're a regular user of the kind of application where anyone ever thought passwords were a valid authentication solution, you don't benefit from a hardware key.
And it's not just a question of more security than necessary: using a security mechanism that is overkill for your needs can actually leave you with lower total security, because you'll end up doing things to make your life more convenient that are worse than what you'd have done with a weaker mechanism (like in the physical case leaving the door unlocked to avoid locking yourself out).
I guess my point is: "don't ignore your tech-savvy users".
And more generally, don't think that 99.9999% of your users are morons. In this case, all it costs is to leave an alternative in the list.
Too much of the modern software completely sucks because the industry is obsessed with "hiding complexity". We should not hide complexity, we should offer abstractions on top, and leave access to the lower-level as much as possible.
And more generally, don't think that 99.9999% of your users are morons. In this case, all it costs is to leave an alternative in the list.
Too much of the modern software completely sucks because the industry is obsessed with "hiding complexity". We should not hide complexity, we should offer abstractions on top, and leave access to the lower-level as much as possible.
I think the passkeys would have remained a great idea if all passkeys were provided either by hardware devices not sold by cloud services vendors, or by software not written by OS vendors.
I largely agree with your point, and I don't think most users should be using hardware tokens. But the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.
I stand by my original statement that the standard was fine until users started getting shoehorned into "use Google passkeys on your Android".
I largely agree with your point, and I don't think most users should be using hardware tokens. But the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.
I stand by my original statement that the standard was fine until users started getting shoehorned into "use Google passkeys on your Android".
[deleted]
> by software not written by OS vendors.
In an ideal world, I'd prefer that to.
In the practical one we're living in, this would mean that almost no website would implement them, because almost no user would be capable of using them.
As much as I dislike the platform lock-in consequences, bootstrapping a two-sided network is incredibly hard and usually does not succeed without something aggressively pushed onto users (e.g. by preinstalling and preselecting it) to kickstart things. In the best case, this is then quickly replaced by user choice, and that's what has fortunately happened for passkeys.
> the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.
Do you mean TPM as a generic term for a hardened secure element/enclave? Unfortunately, these are not standardized at this point (actual TPMs are, but these are a PC thing).
And what would be the point? I could see secure enclaves/elements implementing CTAP2 instead of a proprietary interface, but I don't really see the benefits of that. The much more important thing would be that all applications on the OS can access that implementation through some API, and that would reasonably be the "FIDO backend" APIs both iOS and Android already provide.
In an ideal world, I'd prefer that to.
In the practical one we're living in, this would mean that almost no website would implement them, because almost no user would be capable of using them.
As much as I dislike the platform lock-in consequences, bootstrapping a two-sided network is incredibly hard and usually does not succeed without something aggressively pushed onto users (e.g. by preinstalling and preselecting it) to kickstart things. In the best case, this is then quickly replaced by user choice, and that's what has fortunately happened for passkeys.
> the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.
Do you mean TPM as a generic term for a hardened secure element/enclave? Unfortunately, these are not standardized at this point (actual TPMs are, but these are a PC thing).
And what would be the point? I could see secure enclaves/elements implementing CTAP2 instead of a proprietary interface, but I don't really see the benefits of that. The much more important thing would be that all applications on the OS can access that implementation through some API, and that would reasonably be the "FIDO backend" APIs both iOS and Android already provide.
> 10 recovery codes
Mostly unrelated, I fondly remember Google doing one of those "prove you're you" checks when I was in a different state, allowing me to waste one of my 10 recovery codes as one of the options, and still refusing to let me log back in till I got back on my home WiFi a few weeks later.
Mostly unrelated, I fondly remember Google doing one of those "prove you're you" checks when I was in a different state, allowing me to waste one of my 10 recovery codes as one of the options, and still refusing to let me log back in till I got back on my home WiFi a few weeks later.
> Physical keys work because locksmiths exist,
Physical keys are not a security tool. They are a tamper evidence tool.
> have no equivalent of locksmiths
...because there is always someone on the other side of the door who is entitled to change the lock for you.
> Hardware keys were designed for a spherical humanity
They were just designed for a world where there is actual customer service. This apprehension on hardware keys seems to be rooted mostly in this fact.
Physical keys are not a security tool. They are a tamper evidence tool.
> have no equivalent of locksmiths
...because there is always someone on the other side of the door who is entitled to change the lock for you.
> Hardware keys were designed for a spherical humanity
They were just designed for a world where there is actual customer service. This apprehension on hardware keys seems to be rooted mostly in this fact.
I think a critical feature is missing that makes this almost entirely unworkable: usable handling of backup tokens. There is no way to register a token in a safe. There is no way to name a token to keep track of which one it is. There is no intelligent way to migrate from one token to a new one. Working with two computers with mutually incompatible ports is incredibly annoying.
NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model.
Also: the cloud vendor passkeys (Apple, Google, etc) are far more secure against an attacker that steals a device.
This is not to say that cloud based passkeys are amazing. AFAICT there is nothing remotely resembling an automated way to rotate a key. I’m not even convinced it can be done manually in a straightforward manner. This is not so great, given that a passkey is effectively an unlimited lifetime key pair with no revocation mechanism, that may well be stored without hardware security and that can be propagated to different generations of devices. Also, what happens if a device is stolen and compromised at least enough to keep its password manager running?
NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model.
Also: the cloud vendor passkeys (Apple, Google, etc) are far more secure against an attacker that steals a device.
This is not to say that cloud based passkeys are amazing. AFAICT there is nothing remotely resembling an automated way to rotate a key. I’m not even convinced it can be done manually in a straightforward manner. This is not so great, given that a passkey is effectively an unlimited lifetime key pair with no revocation mechanism, that may well be stored without hardware security and that can be propagated to different generations of devices. Also, what happens if a device is stolen and compromised at least enough to keep its password manager running?
> NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model.
No, the CTAP standard (what FIDO is using for communication with NFC tokens) provides pretty good resistance against this threat. There's actually a diffie-helman key exchange between the computer (platform) and authenticator (token). The only way it could really be better is if it did challenge-response for your PIN authentication, but as it is if you eavesdrop a CTAP NFC exchange you do not get the user's PIN, or the ability to generate/use a credential later.
In order to attack a CTAP token over NFC you need to man-in-the-middle it.
No, the CTAP standard (what FIDO is using for communication with NFC tokens) provides pretty good resistance against this threat. There's actually a diffie-helman key exchange between the computer (platform) and authenticator (token). The only way it could really be better is if it did challenge-response for your PIN authentication, but as it is if you eavesdrop a CTAP NFC exchange you do not get the user's PIN, or the ability to generate/use a credential later.
In order to attack a CTAP token over NFC you need to man-in-the-middle it.
In order to attack a CTAP token, I can tap it against an ordinary phone or a Proxmark or any PN532 device attached to a computer with some fairly straightforward software. There isn’t any authentication! It could be ECDH or SnakeOil-102400-super unbreakable for all an attacker cares: the attacker can just speak the protocol as specified.
edit: Okay, I found the pinToken mechanism in the spec. It is, to put it politely, not a PAKE. It has a trivial DoS attack by design allowing anyone nearby to destroy an authenticator. It looks vulnerable to an attack in which someone taps a malicious token against a phone or other reader, triggering the phone to try to authenticate, and thus captures the PIN, hashed but not even salted.
Oh, and I’ve personally never been prompted to set a PIN, and the UX looks miserable.
edit: Okay, I found the pinToken mechanism in the spec. It is, to put it politely, not a PAKE. It has a trivial DoS attack by design allowing anyone nearby to destroy an authenticator. It looks vulnerable to an attack in which someone taps a malicious token against a phone or other reader, triggering the phone to try to authenticate, and thus captures the PIN, hashed but not even salted.
Oh, and I’ve personally never been prompted to set a PIN, and the UX looks miserable.
That's why you either use authenticators as a second factor only (i.e. you require a password entry first), or you require user verification (which is usually a PIN entry verified by the authenticator). Both solve this problem.
Oh, one more thing!
> There is no way to name a token to keep track of which one it is
Tokens support listing which credentials are stored on them, and most (not 100%, but most) tokens also support storing an arbitrary blob of data at least 1024 bytes in size. You can name your token if you want to name your token.
> There is no way to name a token to keep track of which one it is
Tokens support listing which credentials are stored on them, and most (not 100%, but most) tokens also support storing an arbitrary blob of data at least 1024 bytes in size. You can name your token if you want to name your token.
This does absolutely nothing to help me keep track of which physical gadget matches which token listed in the GitHub 2FA page without manually typing some kind of descriptor and hopefully getting it right.
Github lets me name my passkeys. There's a little pencil icon next to each one (on [1]), and as far as I remember it even prompted me for a name when I originally created it.
[1] https://github.com/settings/security
[1] https://github.com/settings/security
Indeed. But it’s on me to manage it. There ought to be a way to tell my computer, once, the name of a token.
There does seem to be some way. I'm relatively sure I've seen keys pre-labeled with the name of my password manager in the past.
Some sites make bad assumptions, though, e.g. labeling every passkey I create as "iCloud Keychain" (because my user agent tells them I'm on macOS, and they assume that it must be that then).
Some sites make bad assumptions, though, e.g. labeling every passkey I create as "iCloud Keychain" (because my user agent tells them I'm on macOS, and they assume that it must be that then).
> The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise. [...] The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware
Completely untrue. Both iOS/macOS and Android offer an API for third party passkey implementations ("backends"). macOS also offers a client API for that that browsers ("frontends") can hook into. You can use Strongbox (a KeePass implementation) with Chrome, iCloud Keychain with Firefox, a Yubikey with Safari...
It's really as open an ecosystem as it gets at this point, and for software implementations, there isn't even attestation that could allow relying parties to block any specific implementation.
> The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor [...]
No, this "ideal state" is in fact the reality I've been experiencing for the past few months.
Completely untrue. Both iOS/macOS and Android offer an API for third party passkey implementations ("backends"). macOS also offers a client API for that that browsers ("frontends") can hook into. You can use Strongbox (a KeePass implementation) with Chrome, iCloud Keychain with Firefox, a Yubikey with Safari...
It's really as open an ecosystem as it gets at this point, and for software implementations, there isn't even attestation that could allow relying parties to block any specific implementation.
> The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor [...]
No, this "ideal state" is in fact the reality I've been experiencing for the past few months.
If this is so, could you explain why the dialog for a Google Play Services webauthn login today says "use passkey" (meaning "use google-account-hosted passkey") and "try another way" (meaning "present an options page to let me choose, after another click, a passkey that doesn't happen to be a google one")? How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key?
Yes, it's technically possible to use hardware keys today. No, it's not ideal - specifically, what's broken is:
* the user experience where all three major platforms attempt to make it more difficult to use anything other than their platform.
* the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options
* the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME
> there isn't even attestation that could allow relying parties to block any specific implementation
This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" and a signed attestation certificate that does, in fact, allow blocking particular implementations.
Yes, it's technically possible to use hardware keys today. No, it's not ideal - specifically, what's broken is:
* the user experience where all three major platforms attempt to make it more difficult to use anything other than their platform.
* the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options
* the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME
> there isn't even attestation that could allow relying parties to block any specific implementation
This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" and a signed attestation certificate that does, in fact, allow blocking particular implementations.
> How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key?
> * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME
This doesn't happen once you disable iCloud Keychain as an autofill option in the device settings in favor of a third-party integration. You could of course argue that it's anticompetitive of Apple to enable their integration by default, but I had to do this exactly once, not every time.
> This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID"
Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases.
> the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options
This would be nice from a usability point of view, but it sounds like a nightmare to do securely. I'd be fine with a one-time import/export option, and that's being worked on.
> * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME
This doesn't happen once you disable iCloud Keychain as an autofill option in the device settings in favor of a third-party integration. You could of course argue that it's anticompetitive of Apple to enable their integration by default, but I had to do this exactly once, not every time.
> This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID"
Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases.
> the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options
This would be nice from a usability point of view, but it sounds like a nightmare to do securely. I'd be fine with a one-time import/export option, and that's being worked on.
>Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases.
The discussion was about passkeys as a standard, so "well right now Google and Ape happen not to use this part of it" doesn't really change that. It could change tomorrow for all we know and there'd be nothing to be done about it.
By the people on HN who stay away from passkeys, this is one of the most commonly named reasons.
The discussion was about passkeys as a standard, so "well right now Google and Ape happen not to use this part of it" doesn't really change that. It could change tomorrow for all we know and there'd be nothing to be done about it.
By the people on HN who stay away from passkeys, this is one of the most commonly named reasons.
> It's really as open an ecosystem as it gets at this point
However, they fumbled the introduction by trying the “maximum vendor lock” approach first. Now they need to convince everyone otherwise, even if technically it’s open now.
However, they fumbled the introduction by trying the “maximum vendor lock” approach first. Now they need to convince everyone otherwise, even if technically it’s open now.
I also wish they'd have started off like that from the beginning.
It might have taken them a bit longer to get the initial implementation out the door, but it would have avoided all of these discussions, which I'm certain are also impacting WebAuthN/passkey adoption across the web (assuming that the views on passkeys here are at least somewhat representative of technical decisionmakers).
But if the choice is between getting to the status quo via suboptimal intermediate steps or not having WebAuthN and passkeys at all, the former seems much preferable.
It might have taken them a bit longer to get the initial implementation out the door, but it would have avoided all of these discussions, which I'm certain are also impacting WebAuthN/passkey adoption across the web (assuming that the views on passkeys here are at least somewhat representative of technical decisionmakers).
But if the choice is between getting to the status quo via suboptimal intermediate steps or not having WebAuthN and passkeys at all, the former seems much preferable.
I disagree somewhat that that is a "fumble" so much as a symptom of what was necessary to get mainstream acceptance, what a lot of us on HN see as "maximum vendor lock" is also an attempt at building a "pit of success" for average, "boring" users. An "Uncle Charlie" with an iPhone, an iPad, and a Mac that trusts Apple and was already using iCloud Keychain as their primary password manager is going to have an easy time with passkeys and is going to have a harder time accidentally enrolling a passkey they don't understand or know how to use the next time or next device they login from. That's a reasonable "pit of success" for an average, "boring" user.
There's a lot of users that isn't great for. Especially there are statistically a lot of iOS users that use Windows desktop/laptops that Microsoft and Apple are trying to bridge but don't always have the best UX today. Same for Android and Windows users, there's statistically even more of those.
Also, as you can tell from HN comments every time Passkeys come up, HN is full of anecdotes of the craziest mixed device ecosystems people can build. We can be a loud set of users, and we certainly need the most convincing that our "power user" needs are met for all of our complexity requirements.
There's a lot of users that isn't great for. Especially there are statistically a lot of iOS users that use Windows desktop/laptops that Microsoft and Apple are trying to bridge but don't always have the best UX today. Same for Android and Windows users, there's statistically even more of those.
Also, as you can tell from HN comments every time Passkeys come up, HN is full of anecdotes of the craziest mixed device ecosystems people can build. We can be a loud set of users, and we certainly need the most convincing that our "power user" needs are met for all of our complexity requirements.
I largely agree, except for this:
> anecdotes of the craziest mixed device ecosystems people can build
All it takes is for somebody to use both an iPad and an Android phone. iPads are relatively cheap (cheaper than many Windows laptops!); iPhones are quite expensive. That's a lot of users right there, and I think it must be at least as common as Windows + iOS users.
> anecdotes of the craziest mixed device ecosystems people can build
All it takes is for somebody to use both an iPad and an Android phone. iPads are relatively cheap (cheaper than many Windows laptops!); iPhones are quite expensive. That's a lot of users right there, and I think it must be at least as common as Windows + iOS users.
Right. That is not what I meant by "craziest mixed device ecosystems", and yes, I agree that Android + iPad is a common enough situation that needs good defaults that we haven't yet entirely solved for (but there are options today and hopefully it will get better). Windows "knows" it has to be a bridge device with whatever the user's phone ecosystem is, iPadOS today mostly assumes the user's phone "must be" an iPhone. From Apple's perspective that still makes sense as a useful "default" for what they consider to be their average user.
> No, this "ideal state" is in fact the reality I've been experiencing for the past few months.
I agree that technically, it seems possible to choose between hardware keys and OS passkey. But I also agree with the article that they try to push their own solution by hiding the alternatives, and that should not be allowed.
I agree that technically, it seems possible to choose between hardware keys and OS passkey. But I also agree with the article that they try to push their own solution by hiding the alternatives, and that should not be allowed.
Every passkey setup flow I've ever seen has allowed me to use a hardware key or the OS provided store. Am I missing something?
Have you:
A) read the article, paying particular attention to the screenshots therein (ESPECIALLY particularly to the user experience on an Apple device), and
B) noted the part of my comment where I say that I should be able to set the choice of using hardware keys one time instead of needing to do so every time I create a new credential?
Today it's so hard to use a hardware key with Google Play Services that I (a software developer who actually works in this field) have had users tell me their phone didn't let them do it at all. In reality, the support was there, is was just so unusable they didn't even understand they had that option.
A) read the article, paying particular attention to the screenshots therein (ESPECIALLY particularly to the user experience on an Apple device), and
B) noted the part of my comment where I say that I should be able to set the choice of using hardware keys one time instead of needing to do so every time I create a new credential?
Today it's so hard to use a hardware key with Google Play Services that I (a software developer who actually works in this field) have had users tell me their phone didn't let them do it at all. In reality, the support was there, is was just so unusable they didn't even understand they had that option.
Some flows might allow only Platform authenticators (disallowing external hardware keys)
https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
https://www.reddit.com/r/webauthn/comments/197ggm7/comment/k...
The only one that I witnessed, is the optional passkey for restoring your Whatsapp account
https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
https://www.reddit.com/r/webauthn/comments/197ggm7/comment/k...
The only one that I witnessed, is the optional passkey for restoring your Whatsapp account
> installing a password manager providing passkeys would prompt to change the setting to use the password manager instead
iOS supports this today. If a password manager app describes that it implements passkey management, iOS asks what you want to be the default and the UI changes a bit to allow easier choices between iCloud and your password manager app.
It sounds like macOS is the place where Apple is lagging the most on API hooks that applications can use to trigger the UX.
It's also possible that Apple is just prioritizing that macOS users are mostly bought into the iCloud Keychain and their cloud infrastructure whereas iOS does have a large known mixture of iOS/Windows users that may bring their own keychains/password managers.
iOS supports this today. If a password manager app describes that it implements passkey management, iOS asks what you want to be the default and the UI changes a bit to allow easier choices between iCloud and your password manager app.
It sounds like macOS is the place where Apple is lagging the most on API hooks that applications can use to trigger the UX.
It's also possible that Apple is just prioritizing that macOS users are mostly bought into the iCloud Keychain and their cloud infrastructure whereas iOS does have a large known mixture of iOS/Windows users that may bring their own keychains/password managers.
macOS also supports the APIs, but password manager developers don’t seem willing to implement them there.
I’ve used 1Password for a long time, but I’m probably going to drop it for Apple’s password manager because when users ask 1Password to add support, they are directed to use 1Password’s browser extension and universal autofill instead. Neither support passkeys in applications. I also find the browser extension buggy at times (especially with passkeys).
I’ve used 1Password for a long time, but I’m probably going to drop it for Apple’s password manager because when users ask 1Password to add support, they are directed to use 1Password’s browser extension and universal autofill instead. Neither support passkeys in applications. I also find the browser extension buggy at times (especially with passkeys).
I'm aware of iOS' APIs because of Strongbox (iOS Keepass-compatible client), and someone also mentioned that macOS Strongbox does the same thing just fine. That is interesting that in this case it seems specifically a 1Password choice/disinterest.
What is the benefit to Apple?
If all your passkeys are synced to Apple, then it makes it really easy to use that new Apple device and really hard to use that PC/Android Phone/Meta VR headset/etc.
They are trying to make an import/export mechanism to prevent vendor lock in, but what if I want to still use my iPhone and my Meta VR headset. Import/export doesn’t mean sync :(
They are trying to make an import/export mechanism to prevent vendor lock in, but what if I want to still use my iPhone and my Meta VR headset. Import/export doesn’t mean sync :(
Doesn't Apple primarily want the best user experience, and the safest way to use devices? So they should get onboard with what is best for the user.
No, Apple directly benefits in that users only get the "magical" user experience when using Apple devices. There are two perverse incentives: one for Apple to lock their users into their platform, and one for Apple to implement a "better" experience unilaterally. Apple does both of these things.
Today, if I create a passkey on an Apple iPhone, and I pay Apple a monthly fee for iCloud, I can then walk over to an Apple Macbook I own and sign in to the same web site without another step.
But if I don't pay Apple a monthly fee, OR the phone isn't an iPhone, OR the laptop isn't a Macbook, then I don't get that user experience.
There is absolutely no technical reason that I shouldn't be able to get precisely the same level of security and precisely the same user flow without having to need all the devices to be Apple. But Apple chooses to restrict how it can happen.
Today, if I create a passkey on an Apple iPhone, and I pay Apple a monthly fee for iCloud, I can then walk over to an Apple Macbook I own and sign in to the same web site without another step.
But if I don't pay Apple a monthly fee, OR the phone isn't an iPhone, OR the laptop isn't a Macbook, then I don't get that user experience.
There is absolutely no technical reason that I shouldn't be able to get precisely the same level of security and precisely the same user flow without having to need all the devices to be Apple. But Apple chooses to restrict how it can happen.
Why do you say you have to pay a monthly fee for iCloud?
None of the technology you’re discussing here requires a paid account.
You may, separately, decide to sync more than the meager free quota of data on iCloud, but that’s an unrelated issue. You’re welcome to use iCloud just for keychain sync.
None of the technology you’re discussing here requires a paid account.
You may, separately, decide to sync more than the meager free quota of data on iCloud, but that’s an unrelated issue. You’re welcome to use iCloud just for keychain sync.
> Doesn't Apple primarily want the best user experience, and the safest way to use devices?
Presumably, yes.
> So they should get onboard with what is best for the user.
What happens when there’s a conflict? They usually go with the option that screws the smaller niche user base.
Presumably, yes.
> So they should get onboard with what is best for the user.
What happens when there’s a conflict? They usually go with the option that screws the smaller niche user base.
Looks good until Mallory sets up a phishing site that tricks users into installing a thing that registers itself as their “password manager” and mitms their entire life.
Not saying there aren’t other reasons the OS vendors are pushing back on supplying that hook, but that’s one that is at least vaguely pro-user.
Not saying there aren’t other reasons the OS vendors are pushing back on supplying that hook, but that’s one that is at least vaguely pro-user.
TOTP suffers from a similar issue - I use 1Password to store my TOTP codes, but both Google and the UK's HMRC tax website talk about using their own apps for codes rather than anything agreed like "one-time passwords". The digital world is rife with this kind of jockeying for position through language. It took me far too long to understand that "podcasts" are just mp3 files from an RSS feed.
Likewise, in the heyday of interactive TV in the early 2000s, when it was going to conquer the world because everyone had a TV but not a computer, an agency I worked for were invited for a demonstration of a choose-your-own-adventure game they were developing. They kept referencing a "carousel system" where all pages were sent in a looping system and when someone made a choice it waited until that page came round in the "carousel". I kept asking whether that was like Teletext - https://en.wikipedia.org/wiki/Teletext - but they absolutely refused to say that and kept saying "well, it's a carousel system".
This refusal to deal in everyday language, alongside trying to get people to use their own apps / sytems, really hinders the adoption of useful technologies.
Likewise, in the heyday of interactive TV in the early 2000s, when it was going to conquer the world because everyone had a TV but not a computer, an agency I worked for were invited for a demonstration of a choose-your-own-adventure game they were developing. They kept referencing a "carousel system" where all pages were sent in a looping system and when someone made a choice it waited until that page came round in the "carousel". I kept asking whether that was like Teletext - https://en.wikipedia.org/wiki/Teletext - but they absolutely refused to say that and kept saying "well, it's a carousel system".
This refusal to deal in everyday language, alongside trying to get people to use their own apps / sytems, really hinders the adoption of useful technologies.
Not sure what you are talking about TOTP suffering from a similar issue.
TOTP works via a secret key provided by the service. The TOTP(secret key + time) function generates a 6 digit code. This is a standard. The secret key can be stored on Authenticators and those authenticators sync to cloud services.
When adding the secret key for the first time to your authenticator, you have to also copy that to a notepad. This way if you want to transfer the keys, you have them available. Authenticator apps don't always allow you to export the keys. TOTP.app is a good auth app that does allow but there is no sync to cloud capability.
TOTP works via a secret key provided by the service. The TOTP(secret key + time) function generates a 6 digit code. This is a standard. The secret key can be stored on Authenticators and those authenticators sync to cloud services.
When adding the secret key for the first time to your authenticator, you have to also copy that to a notepad. This way if you want to transfer the keys, you have them available. Authenticator apps don't always allow you to export the keys. TOTP.app is a good auth app that does allow but there is no sync to cloud capability.
What I mean is that they don't say "Scan this QR code with your time-based one-time password (TOTP) app." They say "scan this QR code with your Google Authenticator app" or "scan this code with the HMRC app", obfuscating the fact that you can scan that code with any app that supports TOTP authentication like 1Password, Bitwarden, Authy etc. All of those prompts should have a link saying "Click here if you're not sure what TOTP apps are" that goes to a page with links to a whole bunch of recognised authenticator apps, where they can show their own if they want to but also show others that people may already use.
Ah yes! TOTP education takes much time. There are very few people who have invested time in teaching the uninformed about TOTP. OTOH, many more have invested time in developing TOTP apps and hacks.
ffsm8(5)
Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.)
Bitwarden is one of the few that don’t - you can export passkeys, although for now, there’s nothing to import them to unless you want to run a roll your own open source solution.
Bitwarden is one of the few that don’t - you can export passkeys, although for now, there’s nothing to import them to unless you want to run a roll your own open source solution.
KeePassXC imports passkeys from Bitwarden: https://github.com/keepassxreboot/keepassxc/pull/11401/files
KeePassXC and BitWarden win the award for the only open platforms, then.
(And BitWarden isn’t even “free software”!)
(And BitWarden isn’t even “free software”!)
This is extremely obvious in the new FIDO specification for key export, where they neglect to specify the format in which the private keys are encoded.
In other words, it's a "standard" designed to let Apple, Google, and Microsoft enable portability between each other, but to keep software like KeePass out of the mix.
In other words, it's a "standard" designed to let Apple, Google, and Microsoft enable portability between each other, but to keep software like KeePass out of the mix.
Isn’t that here?
https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#...
The private key is specified as being a “PKCS#8 formatted byte string which is then Base64url encoded”. Is that insufficient?
https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#...
The private key is specified as being a “PKCS#8 formatted byte string which is then Base64url encoded”. Is that insufficient?
This really is the least problem.
As long as the key export API isn't actually gated (e.g. by only working over a backend-to-backend API with a mandatory "security audit" to gain access, by wrapping exported keys using vendor-specific keys and requiring a similar audit to be included as an export target etc.), everything else can be figured out. There's only so many ways you can encode an ECDSA key.
As long as the key export API isn't actually gated (e.g. by only working over a backend-to-backend API with a mandatory "security audit" to gain access, by wrapping exported keys using vendor-specific keys and requiring a similar audit to be included as an export target etc.), everything else can be figured out. There's only so many ways you can encode an ECDSA key.
It may partially be because of vendor lock-in, but I think the real reason is security. For example with Apple's Secure Enclave hardware, you give secret-generation responsibility to this chip, and can never see the value. I use it for SSH private keys, which are meant to be disposable/changeable. As much as I want to own and control all my data, I personally think this is pretty good footgun protection, and I'm ok with being unable to export my passkeys from 1password (and for the record, 1password does not prohibit TOTP exports).
If the private key is actually stored in an unbeatable enclave, then fine. Apple’s implementation puts them in your iCloud account, which whilst it is overall locked via the Secure Enclave, the passkeys are most certainly not.
I don’t have a need for a level of security where exporting my private key to, say, Best Buy is impossible.
I don’t have a need for a level of security where exporting my private key to, say, Best Buy is impossible.
[deleted]
One of the Passkeys/WebAuthn spec people made a huge fuss over how KeePassXC did their export function https://github.com/keepassxreboot/keepassxc/issues/10407
[deleted]
Import and export of passkeys is coming "soon" to 1Password (as of October): https://blog.1password.com/fido-alliance-import-export-passk...
I think some vendors do have intentions of locking in users with passkeys (*cough* Apple *cough*), but I also think it's also not the only explanation for why import and export isn't supported by most managers.
A more charitable explanation would be that since passkeys are 'new', there's less people demanding import/export since they have very few passkeys to move around, and at least some vendors wanted to take time to develop a good solution for it / focus resources on actually getting the daily usage of passkeys working.
I think some vendors do have intentions of locking in users with passkeys (*cough* Apple *cough*), but I also think it's also not the only explanation for why import and export isn't supported by most managers.
A more charitable explanation would be that since passkeys are 'new', there's less people demanding import/export since they have very few passkeys to move around, and at least some vendors wanted to take time to develop a good solution for it / focus resources on actually getting the daily usage of passkeys working.
Vendor Locking-In should be classified as an anti competitive practice.
The year is 2025 (almost), and we're still suffering with companies closed garden syndrome.
The year is 2025 (almost), and we're still suffering with companies closed garden syndrome.
> Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.)
Does this mean that any HSM where inability to export the private key is a feature is also doing it for "vendor lockin" reasons?
Does this mean that any HSM where inability to export the private key is a feature is also doing it for "vendor lockin" reasons?
If you’re buying and implementing a HSM, you really ought to understand this concept. After all, you’re getting paid to.
I do not expect random consumers to understand this concept. It’s grossly irresponsible and is simply user abuse.
I love Passkeys. They’re fantastic. I do not love how unportable the implementations for Average Joe and Jane are.
I do not expect random consumers to understand this concept. It’s grossly irresponsible and is simply user abuse.
I love Passkeys. They’re fantastic. I do not love how unportable the implementations for Average Joe and Jane are.
It's both. Most of those vendors have ways to backup those keys securely to same vendor backup product. But they won't let you export them via a wrap or whatever.
It functions both as a security feature and a vendor lock in.
It functions both as a security feature and a vendor lock in.
It's absolutely vendor lock-in, first and foremost. It happens to align with security.
I did a project 10 years ago to sign firmware for embedded devices w/ a planned 25 year product life. I spoke with two different HSM vendors. Both said the Customer would be able to backup and transfer keys from one HSM to another. Both also said that was applicable within their products only. There was no mechanism to switch to another HSM vendor (and neither offered a contingency to get the keys out if the vendor ceased business operations).
Apparently this situation has gotten no better in the last 10 years: https://www.icann.org/en/system/files/files/hardware-securit...
> In April 2023, IANA became aware of the decision by the manufacturer of the Keyper PLUS HSM – the equipment used to store private key materials for the Root Zone KSK – to cease its production of the device. Furthermore, the manufacturer will offer no successor product.
That's ridiculous.
There should be a standards-based protocol to transfer key material between HSMs. It should be tied to physical access using physical tokens. Make the protocol baroque and difficult. Heck, even make it a requirement the source HSM has to to be physically destroyed to complete the process (to prevent "cloning" attacks).
For USB authentication keys this level of cloak-and-dagger LARPing is stupid. There should be a method to export and encrypted copy of the contents of my USB token and, worst case, import it into another token manufactured by the same provider. ("But cloning!" Fine-- tie it to registering the token with the manufacturer along with real-world identity verification. Make it a premium service with an associated cost, if that's what it takes.)
I did a project 10 years ago to sign firmware for embedded devices w/ a planned 25 year product life. I spoke with two different HSM vendors. Both said the Customer would be able to backup and transfer keys from one HSM to another. Both also said that was applicable within their products only. There was no mechanism to switch to another HSM vendor (and neither offered a contingency to get the keys out if the vendor ceased business operations).
Apparently this situation has gotten no better in the last 10 years: https://www.icann.org/en/system/files/files/hardware-securit...
> In April 2023, IANA became aware of the decision by the manufacturer of the Keyper PLUS HSM – the equipment used to store private key materials for the Root Zone KSK – to cease its production of the device. Furthermore, the manufacturer will offer no successor product.
That's ridiculous.
There should be a standards-based protocol to transfer key material between HSMs. It should be tied to physical access using physical tokens. Make the protocol baroque and difficult. Heck, even make it a requirement the source HSM has to to be physically destroyed to complete the process (to prevent "cloning" attacks).
For USB authentication keys this level of cloak-and-dagger LARPing is stupid. There should be a method to export and encrypted copy of the contents of my USB token and, worst case, import it into another token manufactured by the same provider. ("But cloning!" Fine-- tie it to registering the token with the manufacturer along with real-world identity verification. Make it a premium service with an associated cost, if that's what it takes.)
It’s one of the reasons
A YubiKey is not an HSM
A YubiKey is a tiny computer that runs Linux and a built in app… much like most HSMs.
Not just "most passkey stores". The spec has nothing about export/sync, so they've been working around it by hand.
There is a process of drafting a decision to put before the committee to change this ~now[1], but tbh I think the omission from v1 is a strong sign that the omission is literally intentional. I'm sure spec authors will disagree, as I am sure that many are well-meaning... but there are very strong incentives for the current giga-corps to impede and complicate it during design phases, as they are now doing to the UX. If backups and device-loss considerations for such intensely personal data is not baked in, simply, and mandated from day 1, it's intentional by someone.
[1]: https://blog.1password.com/fido-alliance-import-export-passk...
There is a process of drafting a decision to put before the committee to change this ~now[1], but tbh I think the omission from v1 is a strong sign that the omission is literally intentional. I'm sure spec authors will disagree, as I am sure that many are well-meaning... but there are very strong incentives for the current giga-corps to impede and complicate it during design phases, as they are now doing to the UX. If backups and device-loss considerations for such intensely personal data is not baked in, simply, and mandated from day 1, it's intentional by someone.
[1]: https://blog.1password.com/fido-alliance-import-export-passk...
I believe they are trying to make a common import/export mechanism to prevent vendor lock in.
Don't most sites let you create multiple passkeys which would avoid lockin?
Imagine you switch from iOS to Android, now you need to create a new one for every site that need uses passkeys.
Not to mention the hassle if you forgot one.
In most cases it is as simple as: Download the Apple Passwords app on Windows and use it to login to that site on Chrome and then add a new "Google Passkey" in Chrome. It is a hassle, and the UX isn't entirely there today to make it feel "easy" or "seamless", but it is a simple hassle, relatively.
So you have to get a windows machine to switch to android? That doesn't sound like a solution.
No that's just assuming the 70%+ case "average part of the bell curve" where a user switching iOS to Android already has a Windows machine somewhere. Remove the install step of the Apple Passwords app in the rarer case that the user has a Mac or iPad as their primary "other device".
(If the hypothetical user was using Linux machines already by that point, they wouldn't have been using iOS Keychain for their Passkeys in the first place and probably would have the necessary skills or tech guru friend to load up Apple Passwords in a WINE session or in a Windows VM/dual boot.)
All else fails, there's always most sites will continue to (forever) fallback to email-based recovery because we should all face it that email accounts have been the average user's primary password manager for decades anyway.
(If the hypothetical user was using Linux machines already by that point, they wouldn't have been using iOS Keychain for their Passkeys in the first place and probably would have the necessary skills or tech guru friend to load up Apple Passwords in a WINE session or in a Windows VM/dual boot.)
All else fails, there's always most sites will continue to (forever) fallback to email-based recovery because we should all face it that email accounts have been the average user's primary password manager for decades anyway.
I mean... i register in my most common one, and if i cant use that passkey store on another pc like at work... i just ... register another passkey there, you do it once an your done, once at home and once at work,
While I agree with many of the points raised by the author, I guess I just had much much more pessimistic expectations than they did. If I were to write an article on the topic, I'd probably end up listing the exact same factual information, but with the opposite spin: "This is progressing much quicker and more smooth than I would have anticipated!"
Switching from passwords to passkeys is a big change in the entire security model of the modern user-facing internet. We shouldn't be at all surprised that people are both cautious and opinionated about how it should be done, how to migrate users, and how to deal with fallbacks.
Yes, the current situation is one that is messy and not significantly more secure than the previous status quo, but the direction of travel seems at least promising.
I wouldn't actually want my bank to overnight decide that passkeys are the way to log in, and if I use a passkey there should be no insecure fallback options. I want my bank to roll out a passkey, and figure out the infrastructure around it, probe for problems, and allow fallbacks that are equivalent to their previous systems. Similarly, I wouldn't want every passkey management implementation to instantly coalesce around one specific set of management practices and UX. I want various ideas to be tried out and see what comes out of it, even if some of those experiments are bad.
Switching from passwords to passkeys is a big change in the entire security model of the modern user-facing internet. We shouldn't be at all surprised that people are both cautious and opinionated about how it should be done, how to migrate users, and how to deal with fallbacks.
Yes, the current situation is one that is messy and not significantly more secure than the previous status quo, but the direction of travel seems at least promising.
I wouldn't actually want my bank to overnight decide that passkeys are the way to log in, and if I use a passkey there should be no insecure fallback options. I want my bank to roll out a passkey, and figure out the infrastructure around it, probe for problems, and allow fallbacks that are equivalent to their previous systems. Similarly, I wouldn't want every passkey management implementation to instantly coalesce around one specific set of management practices and UX. I want various ideas to be tried out and see what comes out of it, even if some of those experiments are bad.
The article you would write is the right article! But it wouldn't get shared and make the first page of HN.
It's entirely possible people have written exactly the article you want, but our discovery mechanisms are all based on aggregate emotional reaction.
It's entirely possible people have written exactly the article you want, but our discovery mechanisms are all based on aggregate emotional reaction.
I think passkeys are a failed product. Time to give up and start over again.
I don't say this casually. I have been arguing for ending passwords for nearly 20 years now. I'm a software engineer and broadly understand a lot of security protocols. I spent hours understanding passkeys and figuring out how to use them in my environment. The core idea is great! But the usability is garbage.
I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me. All passkeys do now is clutter up the one login flow that works for me (1Password form filling, as awful as that is.)
I don't say this casually. I have been arguing for ending passwords for nearly 20 years now. I'm a software engineer and broadly understand a lot of security protocols. I spent hours understanding passkeys and figuring out how to use them in my environment. The core idea is great! But the usability is garbage.
I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me. All passkeys do now is clutter up the one login flow that works for me (1Password form filling, as awful as that is.)
> All passkeys do now is clutter up the one login flow that works for me
You can always disable that in the settings with one click.
> I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me.
I can't speak for how bad things are on Windows, but my flow on macOS (Firefox) and iOS (Safari) is the following:
- Try to set up a passkey at a site offering them.
- Log out and attempt to log back in using the passkey. If it works (and it does for 80-90% of all sites), great, use it in the future!
- If it doesn't work, delete the passkey, make a mental (or actual, in the password manager) note that the site has a broken implementation or very bad user experience, for future shaming in threads such as this. (Hi, Amazon and Paypal!)
Obviously that's not viable for non-technical users, but it does save me a lot of time in the long run, since every subsequent login is so much faster than using whatever second factor sites are requiring me to provide otherwise.
You can always disable that in the settings with one click.
> I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me.
I can't speak for how bad things are on Windows, but my flow on macOS (Firefox) and iOS (Safari) is the following:
- Try to set up a passkey at a site offering them.
- Log out and attempt to log back in using the passkey. If it works (and it does for 80-90% of all sites), great, use it in the future!
- If it doesn't work, delete the passkey, make a mental (or actual, in the password manager) note that the site has a broken implementation or very bad user experience, for future shaming in threads such as this. (Hi, Amazon and Paypal!)
Obviously that's not viable for non-technical users, but it does save me a lot of time in the long run, since every subsequent login is so much faster than using whatever second factor sites are requiring me to provide otherwise.
>Log out and attempt to log back in using the passkey. If it works (and it does for 80-90% of all sites)
... and right there is a big part of the reason I distrust the current passkey implementations. That's an absurdly low success rate, and I see similar numbers echoed by many people who use them, regardless of the site's importance to their life or apparent technical ability. (my own dabbling has an even worse success rate, though I've somehow managed to dodge multiple complete-passkey-data-loss issues in clients)
And for some reason it doesn't seem to be getting much more consistently working either.
... and right there is a big part of the reason I distrust the current passkey implementations. That's an absurdly low success rate, and I see similar numbers echoed by many people who use them, regardless of the site's importance to their life or apparent technical ability. (my own dabbling has an even worse success rate, though I've somehow managed to dodge multiple complete-passkey-data-loss issues in clients)
And for some reason it doesn't seem to be getting much more consistently working either.
I seem to be in the minority of HN users that love passkeys. I use them for any login that I reasonably can. When creating a passkey I create one in iCloud Keychain as well as in 1Password. I do agree that there needs to be a better import/export story, but I have confidence that will come.
Same here. My passkeys are in Bitwarden and they're more complex and secure than any password websites will let me enter.
I don't trust cloud providers like Google and Apple to keep my secrets for me, but with Bitwarden I can just dump the secrets and load them from a backup if I wish to do so.
I've also been pleasantly surprised at how well logging in through CTAP2 works. Any laptop/desktop PC with Bluetooth can use the Bitwarden vault on my phone (after unlocking it with a password, of course) to log in with very little hassle. Much better than copying over passwords, or opening the password vault on every PC I need to log in to something.
I don't trust cloud providers like Google and Apple to keep my secrets for me, but with Bitwarden I can just dump the secrets and load them from a backup if I wish to do so.
I've also been pleasantly surprised at how well logging in through CTAP2 works. Any laptop/desktop PC with Bluetooth can use the Bitwarden vault on my phone (after unlocking it with a password, of course) to log in with very little hassle. Much better than copying over passwords, or opening the password vault on every PC I need to log in to something.
Same. It is annoying to dodge the prompts that guide me to save in Chrome or iCloud instead of 1Password, but with patience I have always succeeded. Of course, I know what I want and when to ignore what the machine suggests, which I wouldn’t expect of non-enthusiasts.
I would even get idea to make passkeys non-exportable, but lack of import feature for me as power user just kills passkeys for me.
There is a draft spec for transferring keys between password managers. It's complex because they don't want to make it possible to have your passwords dumped insecurely on your computer. But to have them transferred directly between credential stores securely.
Smart to have two sets to avoid complete lock in.
It’s invisible. A black box, non transferable. There’s no mental model that maps and you can’t back it up as a normal person. Implementations are half baked and still require all the rest, all the attack surface is even larger.
Was super excited, totally not anymore.
Was super excited, totally not anymore.
As a technical user who understands how these work and has none of the confusion issues the author describes, my biggest problem and the reason I stopped using them for google is they seem to arbitrarily set the session length for passkey authenticated sessions much lower. I found myself needing to reauthenticate with google every day or 2 when signing in via pass key. I assume the developers thought this would be seamless, but it is a very annoying interruption to workflow. Especially since I use 1password as the backend with my laptop screen closed it results in me needing to type my (long and complicated) password manager password every time and usually when I am trying to access something timely like a meeting invitation.
I think the elephant in the room is the total lack of website/framework/library support Fido has. Trying to implement support on any random site is about as insane as rolling your own crypto and having the single sign on bolt on is sort of how people selling FOSS+enterprise want it.
The end result is that it was more a standard for them more than for direct use by the little sites, and password managers getting involved only furthers that enterprise industry standard feel.
The end result is that it was more a standard for them more than for direct use by the little sites, and password managers getting involved only furthers that enterprise industry standard feel.
It's rather simple actually: https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent..., no crypto involved
on the client side, it seems like it should be simple. in the time i allowed myself, i was not able to figure out how to integrate it server-side in my python app. you're not implementing your own crypto, but you are having to interact with and understnad crypto.
there doesn't seem to be a standard python implementation, and there's no feedback at all about what went wrong if your challenges/responses are not accepted by the client-side APIs. the error if your server-side implementation sends anything unexpected is essentially "no, that's wrong".
there doesn't seem to be a standard python implementation, and there's no feedback at all about what went wrong if your challenges/responses are not accepted by the client-side APIs. the error if your server-side implementation sends anything unexpected is essentially "no, that's wrong".
This doesn't look all that hard: https://github.com/mkalioby/django-passkeys but I guess it depends on how low-level your backend is.
I would personally separate auth and the application. Configuring something like Keycloak or Authelia or one of the many other alternatives to do all the difficult work for you and just logging in through SSO/SAML seems much easier than having to keep track of your own authentication rules/security hashes/salting/etc. without making a mistake.
I would personally separate auth and the application. Configuring something like Keycloak or Authelia or one of the many other alternatives to do all the difficult work for you and just logging in through SSO/SAML seems much easier than having to keep track of your own authentication rules/security hashes/salting/etc. without making a mistake.
if the solution is introducing a whole new third-party authentication provider to my existing app, i'd say that definitely counts as hard.
i spent a few minutes looking into it again, and remembered what i really found frustrating - it's all a weird mix of JSON, and byte arrays. some functions want json, and some functions want json encoded as a byte array. and some of the items in the json structure are supposed to be byte arrays?
it seems like they've gone out of their way to make it purposefully difficult to communicate between the client and the server. there's client examples to follow, and server examples to follow, but getting something between the two of them is a mystery. json doesn't have a byte array type, so making an api that depends on byte arrays in json seems needlessly obtuse. it's a standard that doesn't work without client-server communication, and it hasn't bothered to define a client-server communication method or use a datatype that can be natively communicated to the server?
it seems like they've gone out of their way to make it purposefully difficult to communicate between the client and the server. there's client examples to follow, and server examples to follow, but getting something between the two of them is a mystery. json doesn't have a byte array type, so making an api that depends on byte arrays in json seems needlessly obtuse. it's a standard that doesn't work without client-server communication, and it hasn't bothered to define a client-server communication method or use a datatype that can be natively communicated to the server?
Unfortunately, that's probably way too technical for most developers nowadays, who are almost proud of not being able to read a manual.
That's just the browser client part of the equation, this says nothing about the server side. The `challenge` part of the API, as well as storing and maintaining the necessary public keys and doing the actual validation of credentials, are left for the reader to implement in the backend.
The browser API makes it easy to program a client against passkeys, but that doesn't necessarily hold up for doing the server implementation. For that, you need to either find a library that matches your requirements, or read through guides like these: https://developers.google.com/identity/passkeys/developer-gu... that skim over a lot of details.
The browser API makes it easy to program a client against passkeys, but that doesn't necessarily hold up for doing the server implementation. For that, you need to either find a library that matches your requirements, or read through guides like these: https://developers.google.com/identity/passkeys/developer-gu... that skim over a lot of details.
Yeah right, its easy to write a PAM module too, but configuring an authentication registration and flow is not actually a similar skill set.
Yeah, it has been frustrating me lately that there isn't a simple drop-in Passkeys-only library/framework yet. Right now the best advice is "use Auth0/Okta or competitor and configure them in Passkey-only" which adds a vendor where you shouldn't need a vendor.
The other day I just wanted to store passkeys in Deno KV without feeling like I was rolling my own crypto library. I did not succeed in the limited amount of free time I had on that personal project, and that seemed a shame and a half.
The other day I just wanted to store passkeys in Deno KV without feeling like I was rolling my own crypto library. I did not succeed in the limited amount of free time I had on that personal project, and that seemed a shame and a half.
It gets worse. U2F keys were stateless, the site key pair was stored by the site (encrypted to, and by, the u2f key). Now, passkeys are stored in the device, and, you guessed it - they have a limited number of slots.
The fido2 situation is really bad.
The fido2 situation is really bad.
Not all passkeys need to be stored on the device. This is exactly what things like key-derivation functions are for. You can have a "primary" device key that derives a Passkey based on the site address with maybe a little salt and/or pepper (but maybe not needed with most KDFs).
FIDO2 allows that just fine, it's a complicated dance between the hardware vendor and the OS right now if your particular hardware device uses a full slot per Passkey or derives the Passkey from some "primary" key.
FIDO2 allows that just fine, it's a complicated dance between the hardware vendor and the OS right now if your particular hardware device uses a full slot per Passkey or derives the Passkey from some "primary" key.
25 on my YubiKey. Would 100 be enough?
I have about 1000 accounts in my password manager. 100 passkeys to replace them is not enough. I wouldn't feel comfortable with that as a hard limit, if it's to replace all passwords.
Many of those 1000 are obsolete (old accounts I'll never use again), but many are not. At least 30 are things I use every week, most of them financial or tech admin, i.e. not social media. I'm confident (though not certain) that I login to more than 100 accounts over a typical year, and there are accounts that I sometimes login to more than a year since the previous time, glad that I recorded the credential.
Many of those 1000 are obsolete (old accounts I'll never use again), but many are not. At least 30 are things I use every week, most of them financial or tech admin, i.e. not social media. I'm confident (though not certain) that I login to more than 100 accounts over a typical year, and there are accounts that I sometimes login to more than a year since the previous time, glad that I recorded the credential.
A Yubikey purchased today actually allows 100 discoverable credentials. Keys running older firmware stored a max of 25.
If you don't get old stock - wasn't there some issue recently where they were still selling Yubikeys with the known vulnerability saying that "unless you knew about the vulnerability and specifically had a need to avoid it and told them", that that wasn't a problem?
Thank you
Both are awkward in that I could reasonably expect to exceed them in the lifetime of a hardware authenticator.
The ideal number would be infinite and is in fact very achievable with a very small API modification, but alas, the WebAuthN working group didn't consider it necessary: https://github.com/w3c/webauthn/issues/1822
The ideal number would be infinite and is in fact very achievable with a very small API modification, but alas, the WebAuthN working group didn't consider it necessary: https://github.com/w3c/webauthn/issues/1822
I moves to an android phone to buy a folding phone and I lost all my passkeys. Its a nightmare
This piece reads very nitpicky, and I just don't identify with what it's saying. My use of passkeys in Safari on Apple platforms has been basically seamless.
I guess if you use tons of different browsers on tons of different platforms and want to work in hardware tokens, it's a pain, but most people aren't doing that.
The problems highlighted are real, but they don't rise to the level of "Passkeys aren't usable security". For users that would have otherwise not opted into 2FA at all (or don't know how to set up TOTP), passkeys are fine. I'm sure there are some warts to iron out, but they have to be evaluated within the context of the practical alternatives, not the context of the author's own personal security priorities.
I guess if you use tons of different browsers on tons of different platforms and want to work in hardware tokens, it's a pain, but most people aren't doing that.
The problems highlighted are real, but they don't rise to the level of "Passkeys aren't usable security". For users that would have otherwise not opted into 2FA at all (or don't know how to set up TOTP), passkeys are fine. I'm sure there are some warts to iron out, but they have to be evaluated within the context of the practical alternatives, not the context of the author's own personal security priorities.
I think you're downplaying real concerns people have. Having two different devices is not an exotic scenario
This matches my experience perfectly. As someone who is technically skilled but has no particular security expertise, I've tried to gradually implement passkeys where available across the most important and frequently used of my accounts, and... I'd have to go read the goddamn spec to have any idea what's going on. Pretty much all I've learned is that sometimes I can use touch ID to log into stuff now, and sometimes I can't, and the reasons are totally damn opaque.
Passkeys are simply over-engineered. A passwordless login system need only the following:
- $AUTHENTICATOR is one of (browser extension, browser, OS, hardware) - $AUTHENTICATOR stores mappings ($SITE,$PUBKEY) => $PRIVKEY - $SITE can ask $AUTHENTICATOR to generate a new $PRIVKEY and give it its $PUBKEY - $SITE can ask $AUTHENTICATOR to sign a challenge with the $PRIVKEY corresponding to one of the $PUBKEYs for that $SITE - the user can pick which $PRIVKEYs are synced and which can be exported (depending on $AUTHENTICATOR capabilities)
Bonus points for adding a way to do the authentication off-device through QR codes, so $AUTHENTICATOR one one device can authenticate a session on another device (like using a phone to log into $SITE on the desktop, perhaps for the purpose of adding another authenticator there).
- $AUTHENTICATOR is one of (browser extension, browser, OS, hardware) - $AUTHENTICATOR stores mappings ($SITE,$PUBKEY) => $PRIVKEY - $SITE can ask $AUTHENTICATOR to generate a new $PRIVKEY and give it its $PUBKEY - $SITE can ask $AUTHENTICATOR to sign a challenge with the $PRIVKEY corresponding to one of the $PUBKEYs for that $SITE - the user can pick which $PRIVKEYs are synced and which can be exported (depending on $AUTHENTICATOR capabilities)
Bonus points for adding a way to do the authentication off-device through QR codes, so $AUTHENTICATOR one one device can authenticate a session on another device (like using a phone to log into $SITE on the desktop, perhaps for the purpose of adding another authenticator there).
Fully agree. I'd say the overengineering is to support competing vendor interests and introducing crap like attestations. Though, I believe some extra engineering is needed for the constrained resources on a hardware token authenticator.
Anyone know what adoption rates for passkey looks like now? I think they are cool too, but the constant prompting to create them and invisible/variable UI everywhere is a problem. It presents as inconsistent as compared with the standardized username/password form that grandmas understand.
I will never use Face ID or Fingerprint for any device, but I agree, passkeys are a bit too much. Also, the OSs I use may not support passkeys. They are not on the list.
The magic of password is that you can write them to paper or keep them in your mind. No interoperability issue if suddenly having to use it temporarily or permanently with another device, like if you lose your phone. And you can also pretend they don't exist and no one can prove otherwise. Also if you don't use a password manager, no one (hacker or else) can extract it from your head like it can be forced from your devices.
That password is Hello123! for most people and that's why people get “hacked”. Great that you're one of the dozen or so people who can keep hundreds of passwords in your memory palace for several decades, but that's not feasible for us mortals.
Good passwords are hard because password booklets get lost, or aren't nearby when accounts are created, and people are terrible at remembering hundreds of passwords. Or even ten passwords, as I've found out working helpdesk.
If everyone used passwords safely, we wouldn't need 2FA on all that many services. Unfortunately, credential stuffing remains super effective.
I'm not saying passkeys are the perfect solution here, but pretending passwords are fine as-is is just burying your head into the sand.
Good passwords are hard because password booklets get lost, or aren't nearby when accounts are created, and people are terrible at remembering hundreds of passwords. Or even ten passwords, as I've found out working helpdesk.
If everyone used passwords safely, we wouldn't need 2FA on all that many services. Unfortunately, credential stuffing remains super effective.
I'm not saying passkeys are the perfect solution here, but pretending passwords are fine as-is is just burying your head into the sand.
Realistically passwords can also be forced from your head using 'enhanced interrogation techniques'.
Passkeys deployment reminds me of a cartel agreement among FAANG without the actual coordination. It's too good of a new tech frontier not to colonize.
I haven't used passkeys, I have not been prompted about it, asked to create one, been reminded to change to it, or anything like that. It is like they don't exist to me. Am I supposed to be nagged about it in order to change to it? Or is it something you have to hunt for in the account details of a site? Unsure if I am a late adopter or if the technology has not found me yet.
Google, GitHub, and a few other services have bagged me to create passkeys. I haven’t tried hard to understand how to use them, but at some point I created one on one device and whenever I try to log in from a different device it doesn’t work but passwords and MFA work just fine across devices so I mostly just ignore it. Annoying that a lot of services are pushing passkeys as the default mechanism though.
Did you use 2FA before? I use it, possibly they deem my security good enough because of that?
After reading 1/2 of the article, I still have no idea what a passkey is.
In my limited understanding, they are similar to SSH public/private key pairs. But the details continue to elude me, no matter how much I read about them. Won't try them out until I get how they work.
It’s that, except the OS manages the private key (in a “secure enclave”). So you, the user, (or malware), never get access to the private key.
The second crucial part is that these private keys are cloud synced. This means that the average Joe doesn’t lose their passkeys when they lose their phone. Get a new phone, and it will sync your passkeys and you are back. For people in the Apple ecosystem, it really is a straight upgrade over passwords.
Where it sucks:
- I’m not comfortable trusting a big vendor with the keys to my digital life
- I only have one device, so when I lose that device I’m locked out till I get another
- I want to use my own password manager to handle passkeys
- I am in multiple big vendor ecosystems
- I want to export these private keys (this one is sort of coming, the standard has been defined to allow export and import, but again in such a way that the user (or malware) cannot access these private keys)
The second crucial part is that these private keys are cloud synced. This means that the average Joe doesn’t lose their passkeys when they lose their phone. Get a new phone, and it will sync your passkeys and you are back. For people in the Apple ecosystem, it really is a straight upgrade over passwords.
Where it sucks:
- I’m not comfortable trusting a big vendor with the keys to my digital life
- I only have one device, so when I lose that device I’m locked out till I get another
- I want to use my own password manager to handle passkeys
- I am in multiple big vendor ecosystems
- I want to export these private keys (this one is sort of coming, the standard has been defined to allow export and import, but again in such a way that the user (or malware) cannot access these private keys)
Thanks for the explanation, it was very clear. Especially the bit about never being able to see your own private key. Ok I get it, it's to prevent malware from doing the same, but it still vaguely distasteful.
My understanding: It's like a yubikey (a device that lets you login securely) but using a similar protocol without the hardware. "Virtualized" in other words. Unfortunately susceptible to poor self-serving implementation UI by greedy vendors.
A passkey is a resident webauthn credential.
> chosen to sync the passkey using my 1Password password manager. In theory, that choice allows me to automatically use this passkey anywhere I have access to my 1Password account
I have never used passkeys and don't know much about them, but isn't the main point that they're distinct per device?
If one syncs pass keys using a password manager, what benefit do they bring over passwords?
I have never used passkeys and don't know much about them, but isn't the main point that they're distinct per device?
If one syncs pass keys using a password manager, what benefit do they bring over passwords?
They don't bring any user-visible benefit over passwords if you use a password manager for your password (so that the password is stored securely on disk behind the password manager's login) *and* the password is unique and large (eg randomly-generated by the password manager) *and* you have the password manager autofill it instead of copy-pasting it manually (because the password manager can reliably check the domain name without falling for lookalikes, homoglyphs, etc).
From a UX perspective, passkeys eliminate user choice about the above matters, so it's easier to railroad users into secure-by-default.
From a technical perspective, a shared secret like a password is generally worse than an asymmetric key like a passkey, especially since stupid websites can save the password directly instead of using a KDF in the usual way and then get breached, but if the secret is unique that matters less.
From a UX perspective, passkeys eliminate user choice about the above matters, so it's easier to railroad users into secure-by-default.
From a technical perspective, a shared secret like a password is generally worse than an asymmetric key like a passkey, especially since stupid websites can save the password directly instead of using a KDF in the usual way and then get breached, but if the secret is unique that matters less.
The main benefit: if used to replace passwords, they eliminate bad passwords and password reuse and password leaks by things you log into. Which is a gigantic improvement in practice, as those are extremely common ways for mass account theft.
(I am not personally a fan of passkeys for a variety of reasons, but the main goal is very pragmatic and something like passkeys is a very obvious choice. I just don't like this spec, the UX awfulness and railroad-everyone-into-giga-corp-systems-and-giving-up-all-control shown in this article is a direct and very predictable result of the spec's decisions.)
---
Per-device is an option (part of the spec, and I believe always allowed), but it has a bootstrapping problem that leads to custom out-of-spec shenanigans (how do you attach your account to a second device, without any other way to log in, if the new device has nothing that can prove it's related to the other?) and most people don't have enough devices to be able to have guaranteed backups. Lose your phone and you might lose literally everything. Or a house fire. Data is FAR easier and cheaper to put in multiple locations for redundancy.
Also I set up new devices like a dozen times a year, whether it's a new physical device (relatively rare) or simply an erase and start over / OS switch (at least annually , it ensures my backups work and I get rid of cruft). If my passwords weren't backed up and handled with far more paranoia than my browser session, I've have lost them at least a couple times.
(I am not personally a fan of passkeys for a variety of reasons, but the main goal is very pragmatic and something like passkeys is a very obvious choice. I just don't like this spec, the UX awfulness and railroad-everyone-into-giga-corp-systems-and-giving-up-all-control shown in this article is a direct and very predictable result of the spec's decisions.)
---
Per-device is an option (part of the spec, and I believe always allowed), but it has a bootstrapping problem that leads to custom out-of-spec shenanigans (how do you attach your account to a second device, without any other way to log in, if the new device has nothing that can prove it's related to the other?) and most people don't have enough devices to be able to have guaranteed backups. Lose your phone and you might lose literally everything. Or a house fire. Data is FAR easier and cheaper to put in multiple locations for redundancy.
Also I set up new devices like a dozen times a year, whether it's a new physical device (relatively rare) or simply an erase and start over / OS switch (at least annually , it ensures my backups work and I get rid of cruft). If my passwords weren't backed up and handled with far more paranoia than my browser session, I've have lost them at least a couple times.
It is possible to use distinct passkeys per device, but that's a crappy user experience, similar to having a distinct SSH private key per device (which is also often recommended by naive technologists). You generally want to lean towards turning M * N problems into M + N problems.
I'm so unimpressed with passkeys. It's just like blockchain, trying to solve a poorly defined social and legal problem with pie in the sky 'elegance' and overly complex technological solutions.
I don't think cryptography is the way to solve phishing. I mean sure it can, clearly. Bitcoin also works as a currency, but it hasn't stopped people scamming and stealing money.
If you're a person wondering if you need passkeys: you need a password manager instead. If you learn some basic safety habits and always trust your password manager, you get almost all the benefits of passkeys with almost none of the downsides.
Passwords— if used responsibly— are fine for 99.9% of what anyone wants or needs. To be responsible with passwords, you just let the computer do it. That's really the problem passkeys solve, just in the most typically obnoxious way.
I don't think cryptography is the way to solve phishing. I mean sure it can, clearly. Bitcoin also works as a currency, but it hasn't stopped people scamming and stealing money.
If you're a person wondering if you need passkeys: you need a password manager instead. If you learn some basic safety habits and always trust your password manager, you get almost all the benefits of passkeys with almost none of the downsides.
Passwords— if used responsibly— are fine for 99.9% of what anyone wants or needs. To be responsible with passwords, you just let the computer do it. That's really the problem passkeys solve, just in the most typically obnoxious way.
I'd like to just keep using security keys, thank you very much. They are much simpler and easier to understand and explain.
The best way to solve a big problem is to break it up into lots of tiny problems.
It seems like, IMO, the best way to get the general public to adopt passkeys, and to refine (cough debug cough) the UI, is to use them in low-stakes situations, in a gradual rollout.
Instead of focusing on high-stakes use cases, like banking, perhaps:
1: Focus on low-stakes situations, like blogs and news sites
2: Services need easy ways to "add a device," such as opening a link in an email or SMS on the device they want to use.
3: Don't bother syncing passkeys across "devices." Instead, focus on syncing within the browser, where passkeys sync however bookmarks sync.
4: Work on APIs for a user to elect to use a 3rd party passkey manager
At that point, services like iCloud, OneDrive, Google Drive, ect, could also provide passkey synchronization. It's up to elect to use such services; because otherwise, re-signing-in on each device the user uses might be "good enough."
It seems like, IMO, the best way to get the general public to adopt passkeys, and to refine (cough debug cough) the UI, is to use them in low-stakes situations, in a gradual rollout.
Instead of focusing on high-stakes use cases, like banking, perhaps:
1: Focus on low-stakes situations, like blogs and news sites
2: Services need easy ways to "add a device," such as opening a link in an email or SMS on the device they want to use.
3: Don't bother syncing passkeys across "devices." Instead, focus on syncing within the browser, where passkeys sync however bookmarks sync.
4: Work on APIs for a user to elect to use a 3rd party passkey manager
At that point, services like iCloud, OneDrive, Google Drive, ect, could also provide passkey synchronization. It's up to elect to use such services; because otherwise, re-signing-in on each device the user uses might be "good enough."
regular people strongly disagree. from what i can tell, people who aren't HN commentators or tech bloggers love passkeys.
you click "sign in" and you are signed in. that's the dream. my non-technical family and friends have been lamenting not being able to do that for years. my customers are asking for it.
you click "sign in" and you are signed in. that's the dream. my non-technical family and friends have been lamenting not being able to do that for years. my customers are asking for it.
And that will quickly reverse once people start losing their accounts by losing passkeys or devices.
My extended family fought me about migrating to Signal for years. I stopped trying. One or two years later, they were all on it, acting as if they hadn't given me grief for it.
They have learned their lesson, though. A couple of them have come to me asking about passkeys, and I tell them the threat of losing access and let them make their decision. I think both of them chose to keep passwords.
My extended family fought me about migrating to Signal for years. I stopped trying. One or two years later, they were all on it, acting as if they hadn't given me grief for it.
They have learned their lesson, though. A couple of them have come to me asking about passkeys, and I tell them the threat of losing access and let them make their decision. I think both of them chose to keep passwords.
Every person I've talked to in person who has used passkeys has lost all their passkeys at least once, by no fault of their own.
The more techno-masochistic ones tried again immediately out of curiosity (hence "at least"), but the rest have sworn off passkeys permanently.
And I don't blame them. Without cross-platform sync being standard and literally everywhere, it's trusting hardware and OS vendors to do a good job and inter-operate correctly for the long-term future. They've all used computers for long enough to know that's not something you can trust them with, particularly not in low-margin devices like most people use.
The more techno-masochistic ones tried again immediately out of curiosity (hence "at least"), but the rest have sworn off passkeys permanently.
And I don't blame them. Without cross-platform sync being standard and literally everywhere, it's trusting hardware and OS vendors to do a good job and inter-operate correctly for the long-term future. They've all used computers for long enough to know that's not something you can trust them with, particularly not in low-margin devices like most people use.
i think you're overestimating how good people are about maintaing their passwords. if you tell people "you'll lose your passkey and have to reset it" they'll freak out. but most people lose their passwords and get locked out of their account on a somewhat regular basis anyways. people suck at passwords.
if they can have that level of reliability with a bit more everyday convenience, they'll be happy.
if they can have that level of reliability with a bit more everyday convenience, they'll be happy.
Give it a few more years to marinate, and people start getting new devices. Then we'll see how good this actually works.
[deleted]
I recently switched from Android to iPhone (and had to get a second iPhone because in <2 weeks I got more scratches on my screen than I have on my multiple droid devices used for 5 years...).
I learned a lot about 2FA from that experience... not in a fun way. The problem really comes down to this: let me register >1 devices for authentication! Luckily Google does this but many places don't. So you're kinda fucked if you exchange your device and don't convert everything first. Interfaces are crazy bad. Firefox is a good example: go to manage account, scroll down to "Two-step authentication" and you'll see "Enabled" with an option to "Disable" or "Get new codes". But I registered this into Ente!
Even FIDO keys say you should buy tap two. One to lock in a safe (they should make this easier by allowing some way to clone a key). Why can't I register 2 devices or multiple methods. More so, why can't I set some priority leveling like prefer security key, email if OTP is used, require message to fall back to email OTP.
This isn't just a problem with passkeys, this is a security problem in general. I really don't think there's enough thought put into how things happen in the real world. I'm pretty techy so got my issues solved but if it were my parents? Well they would swear at me for having implemented that security and never trust me again, falling back to much lower security. It's hard to blame them.
So does anyone know the real way to solve these issues? We're on Hacker News. Yes, the best security is if you lose a key you lose access, but this doesn't work for the real world and for most people. You shouldn't be at risk of losing an account if you lose or destroy your phone. We should also have solutions that don't require internet or reliance on big tech 3rd parties that get Metadata as is the case with single signons. Yes, provide that option, but there's got to be a better way (that can also permeate into standard practices!!!)
I learned a lot about 2FA from that experience... not in a fun way. The problem really comes down to this: let me register >1 devices for authentication! Luckily Google does this but many places don't. So you're kinda fucked if you exchange your device and don't convert everything first. Interfaces are crazy bad. Firefox is a good example: go to manage account, scroll down to "Two-step authentication" and you'll see "Enabled" with an option to "Disable" or "Get new codes". But I registered this into Ente!
Even FIDO keys say you should buy tap two. One to lock in a safe (they should make this easier by allowing some way to clone a key). Why can't I register 2 devices or multiple methods. More so, why can't I set some priority leveling like prefer security key, email if OTP is used, require message to fall back to email OTP.
This isn't just a problem with passkeys, this is a security problem in general. I really don't think there's enough thought put into how things happen in the real world. I'm pretty techy so got my issues solved but if it were my parents? Well they would swear at me for having implemented that security and never trust me again, falling back to much lower security. It's hard to blame them.
So does anyone know the real way to solve these issues? We're on Hacker News. Yes, the best security is if you lose a key you lose access, but this doesn't work for the real world and for most people. You shouldn't be at risk of losing an account if you lose or destroy your phone. We should also have solutions that don't require internet or reliance on big tech 3rd parties that get Metadata as is the case with single signons. Yes, provide that option, but there's got to be a better way (that can also permeate into standard practices!!!)
I'm really not convinced by passkeys as a socio-technical phenomenon because it seems to lock people to their OS. As a technical user, having them in 1Password which is OS-neutral (and plans to support export eventually - I'll change my mind on passkeys if this never comes), they're great.
> And forget about trying to use a passkey to log into PayPal on Firefox. The payment site doesn't support that browser on any OS.
I had no idea! That’s pretty awful.
> Somehow, the mysterious entity responsible for this message (it's Google in this case) has hijacked the process in an attempt to convince me to use its platform.
I do not want Google to be managing my passkeys or passwords. Even if they promise to keep them device-local, I frankly don’t believe them: the temptation to make it easy for users who have lost a device or forgotten a password is too strong, and at some point they will take the plaintext, and then it is game over as far as security is concerned.
I had no idea! That’s pretty awful.
> Somehow, the mysterious entity responsible for this message (it's Google in this case) has hijacked the process in an attempt to convince me to use its platform.
I do not want Google to be managing my passkeys or passwords. Even if they promise to keep them device-local, I frankly don’t believe them: the temptation to make it easy for users who have lost a device or forgotten a password is too strong, and at some point they will take the plaintext, and then it is game over as far as security is concerned.
I'll be avoiding them until I'm sure that the attestation object is not being used as a nefarious back channel between the vendor of my authenticating device and the service that wants to authenticate.
The way the protocol is set up now feels like a slippery slope towards a world where I can't be sure that my new accounts aren't actually containing information about whether I had been to a protest recently or whether, at the time of sign-up, my biometrics indicated that I was in an altered state and likely to be easier to fool than usual.
The way the protocol is set up now feels like a slippery slope towards a world where I can't be sure that my new accounts aren't actually containing information about whether I had been to a protest recently or whether, at the time of sign-up, my biometrics indicated that I was in an altered state and likely to be easier to fool than usual.
How about every site and service let me use my username+password combination and stop bothering me with 2-3-4-5FA bullshit? I can manage my own passwords, thank you!
I don't know. If you're in the iOS ecosystem and using iCloud syncing and Safari things are super easy and default more secure than without passkeys. The author's examples of Firefox, chrome, a password manager and a physical key apply to very technical users who seem quite capable of navigating the complexities he complains of.
The vast majority of people are just not going to encounter most of his issues. I sympathize with his issues, but he's kind of complaining that fighting the ecosystem is complicated.
My guess is that <<1% of people use his combination of multiple browsers a non-iCloud pw manager and a physical key on MacOS. And they're not substantially less secure than his setup.
My only issue with passkeys is sites that don't seem to have them figured out yet. They'll let you setup a passkey but then offer to let you sign in with a password first. These seem to be becoming more rare, but even amazon's passkey seems random when it lets me use it. And even then it wants to send me a text message code anyway (this is probably a setting somewhere, so my fault I'm sure).
The vast majority of people are just not going to encounter most of his issues. I sympathize with his issues, but he's kind of complaining that fighting the ecosystem is complicated.
My guess is that <<1% of people use his combination of multiple browsers a non-iCloud pw manager and a physical key on MacOS. And they're not substantially less secure than his setup.
My only issue with passkeys is sites that don't seem to have them figured out yet. They'll let you setup a passkey but then offer to let you sign in with a password first. These seem to be becoming more rare, but even amazon's passkey seems random when it lets me use it. And even then it wants to send me a text message code anyway (this is probably a setting somewhere, so my fault I'm sure).
> They'll let you setup a passkey but then offer to let you sign in with a password first.
I am not sure if that is what you're talking about, but the standard way to implement login with passkeys is to use a normal username/password form and leverage the auto-fill mechanism to offer you to sign with a passkey if it is discoverable.
Another way is to have a two-step login, where you enter your login/email in the first step, and then use passkey to login in the next.
There are benefits and drawbacks in both of them.
Also, passkey can be used with multiple authenticators (like Yubikey), and most popular websites consider that verification of the user is not implemented sufficiently for some of them to be used as the only way of authentication, so they don't allow you to login with them without a second factor (i.e. password).
I am not sure if that is what you're talking about, but the standard way to implement login with passkeys is to use a normal username/password form and leverage the auto-fill mechanism to offer you to sign with a passkey if it is discoverable.
Another way is to have a two-step login, where you enter your login/email in the first step, and then use passkey to login in the next.
There are benefits and drawbacks in both of them.
Also, passkey can be used with multiple authenticators (like Yubikey), and most popular websites consider that verification of the user is not implemented sufficiently for some of them to be used as the only way of authentication, so they don't allow you to login with them without a second factor (i.e. password).
This article links to a bunch of pages at FIDO Alliance, the official passkey info source, pages like https://fidoalliance.org/fido2/
FIDO Alliance's website is pure garbage.
On first load all the content is covered by a demand you "sign up for updates!", a modal blocking the rest of the page. Also there's a surveillance consent popup that opts you in to tracking.
It takes 9.9MB to load this content-free page. Closing the distractions so you can read the content loads another 3MB.
Why would I trust this alliance for anything to do with website creation?
FIDO Alliance's website is pure garbage.
On first load all the content is covered by a demand you "sign up for updates!", a modal blocking the rest of the page. Also there's a surveillance consent popup that opts you in to tracking.
It takes 9.9MB to load this content-free page. Closing the distractions so you can read the content loads another 3MB.
Why would I trust this alliance for anything to do with website creation?
Why is it defaulting to passkey if i want to use a security key... probably because 99% of people will be using the builting apple passkey and not a third party hardware device that few have... hence why the hardware device is considered "other"
It's not merely a default, but a desire to punish outliers to conform.
Forcing a new key pair for every single website was a mistake. If the crypto is secure than a single key pair should be suffice. That is how we use public key crypto almost every other use case and we get to avoid vendor lock in completely.
Every additional factor just weakens the chain. None of these solutions addresses the social attacks due to decreased usability. Users are more confused and have less control now. They will spam every factor to get to their resources.
I guess I am a bit dense when I create Apple passkeys for the few websites that support it, I don’t have any issues with using chrome or safari and macOS or windows? I will test again but I don’t remember experiencing this.
I think there is a big difference in experiences for people who are in the Apple ecosystem and people who aren’t. Apple has made the whole show seamless, so you move from device to device and everything just works, your passkeys are there. At worst, you use your phone to do the login.
It’s also seamless if you lose a device. Your new device has your passkeys, and you can get by with an iPad or older phone until replaced. I think the space where people have all the pain is outside of this ecosystem. Apple is showing it can be done well, but it’s clearly not the experience people are having outside of that walled garden.
It’s also seamless if you lose a device. Your new device has your passkeys, and you can get by with an iPad or older phone until replaced. I think the space where people have all the pain is outside of this ecosystem. Apple is showing it can be done well, but it’s clearly not the experience people are having outside of that walled garden.
As an Apple ecosystem user i really like passkeys. I don’t have to remember passwords and once i set up a passkey on a device it’s synced to all my other devices.
It’s just really convenient.
Why not use something similar to SQRL instead?
https://en.m.wikipedia.org/wiki/SQRL
https://en.m.wikipedia.org/wiki/SQRL
This is from the guy that created a new, unnecessary, cryptographic primitive by chaining multiple invocations of scrypt instead of modifying the parameters/rounds of scrypt.
I wasted an inordinate amount of time trying to fight Apple Vision Pro to get it to read my Yubikey.
I failed. My apple vision pro was rendered useless because of a single passkey.
Dumbest tech ever.
I failed. My apple vision pro was rendered useless because of a single passkey.
Dumbest tech ever.
"Most try to funnel you into a vendor's sync passkey option"
Therein lies the problem. Every vendor's profit motive and #enshittification means they want to own your passkey and all the personal data associated with it. None of the care to interop or work with decentralized solutions. They need your data, and they'll do everything they can to lock you into their jail.
Therein lies the problem. Every vendor's profit motive and #enshittification means they want to own your passkey and all the personal data associated with it. None of the care to interop or work with decentralized solutions. They need your data, and they'll do everything they can to lock you into their jail.
I like the idea of using a password manager, but I think we should be aware that can create a single point of failure. For example, the LastPass breaches.
[deleted]
How is this different than just using your SSH key?
One difference is that it is hardcoded to the destination site.
Maybe someone can explain it better to me.
It seems that the primary goal for passkeys is to eliminate password fishing.
You still need a password for the site. Even with passkeys, you can still login with a password, either from a different machine, or, if nothing else, to recreate your passkey.
But passkeys offer a bit more security to enforce that you're actually sharing the credential with the proper site, correct?
Am I missing something?
I mean, there's the whole syncing passkeys across stuff, but that's all optional. There's no requirement for that. You should be able to configure multiple passkeys to the same site across your various machines (for whatever reason), right?
And I assume the sites won't "auto login"? Even with a passkey you would need to (potentially) hit a login button or something.
I just want to make sure I understand it clearly.
It seems that the primary goal for passkeys is to eliminate password fishing.
You still need a password for the site. Even with passkeys, you can still login with a password, either from a different machine, or, if nothing else, to recreate your passkey.
But passkeys offer a bit more security to enforce that you're actually sharing the credential with the proper site, correct?
Am I missing something?
I mean, there's the whole syncing passkeys across stuff, but that's all optional. There's no requirement for that. You should be able to configure multiple passkeys to the same site across your various machines (for whatever reason), right?
And I assume the sites won't "auto login"? Even with a passkey you would need to (potentially) hit a login button or something.
I just want to make sure I understand it clearly.
I agree with many of the downsides but the only devices I use are Apple. Macs, iPhone, iPad. For me, passkeys are universally simple.
Sorry other OSes and browsers other than Safari, which I switched to specifically for passkeys and Apple Pay, aren't as elegant.
That's Apple's advantage. Their hardware and software ecosystem.
And that's why I never look at anything else.
Sorry other OSes and browsers other than Safari, which I switched to specifically for passkeys and Apple Pay, aren't as elegant.
That's Apple's advantage. Their hardware and software ecosystem.
And that's why I never look at anything else.
The most common lock and key ergonomics that everyone is familiar with is the following:
1. You have a lock, you have a corresponding physical key. You can have more identical physical keys. All of them will unlock the lock. If you lose the physical key, you can call the locksmith to change the lock. Physical key is anonymous. Only you know which key unlocks which lock. If a random person finds your physical key on the street, they shouldn't be able to find their way to your lock to try and unlock it.
2. That's all well and good. Now, comes a magic key. That's your personal magic key. Any lock you are permitted to unlock, your magic key can unlock it. Any key you are not permitted to unlock, your magic key cannot unlock. Now, you can more than one magic key – where only some of the locks you are allowed to unlock can be unlocked by one magic key vs another. And if you happen to lose your magic key, you can call your locksmith to cancel your magic key – actually, that's a keysmith than a locksmith!
3. Your magic key is still anonymous. Only you know which magic key can open which locks. A random person who finds your magic key shouldn't be able to find their way to all the locks it can unlock.
4. When you see a lock, you are prompted to insert a key. The prompt doesn't say which key. You try one of the magic keys have that you think should unlock it. If it happens to the wrong key, not a big deal. You just try another magic key you have, and if that's the correct key it will unlock it.
5. When you buy a new lock (sign-up), you decide which magic key you have that should be the one to unlock it. This pairing of the key to the lock is done simply by asking pair a key to the lock. You are not being told to use a specific vendor of magic keys. You are not being peddled only magic key vendor over another!
6. If you want to change the magic key paired to a lock, you can do so at anytime on your own as long as you are in possession of the current magic key.
7. And of course, you can have multiple magic keys paired to the lock, so that you can unlock with any of the keys.
8. When you use a key to unlock a lock, the lock can tell which paired key was used – you can give nicknames to the paired keys that the lock remembers. The lock will tell you which nicknamed keys were used to unlock it previously and when.
-----
Here's where I think passkeys went awry. They became yet another platform war. The OSes and browsers are supposed to be neutral and provide an unobtrusive prompt for user to pair a key or use a key, that's it. And the user should invoke a keyring against that prompt. If the keyring provider has features – like portability or non-portability of keys etc that's unique to each key ring provider and as long as the user is comfortable with it, everyone should be good with it. The prompt needs to be unassuming. Today it is very assuming and that's the problem!
1. You have a lock, you have a corresponding physical key. You can have more identical physical keys. All of them will unlock the lock. If you lose the physical key, you can call the locksmith to change the lock. Physical key is anonymous. Only you know which key unlocks which lock. If a random person finds your physical key on the street, they shouldn't be able to find their way to your lock to try and unlock it.
2. That's all well and good. Now, comes a magic key. That's your personal magic key. Any lock you are permitted to unlock, your magic key can unlock it. Any key you are not permitted to unlock, your magic key cannot unlock. Now, you can more than one magic key – where only some of the locks you are allowed to unlock can be unlocked by one magic key vs another. And if you happen to lose your magic key, you can call your locksmith to cancel your magic key – actually, that's a keysmith than a locksmith!
3. Your magic key is still anonymous. Only you know which magic key can open which locks. A random person who finds your magic key shouldn't be able to find their way to all the locks it can unlock.
4. When you see a lock, you are prompted to insert a key. The prompt doesn't say which key. You try one of the magic keys have that you think should unlock it. If it happens to the wrong key, not a big deal. You just try another magic key you have, and if that's the correct key it will unlock it.
5. When you buy a new lock (sign-up), you decide which magic key you have that should be the one to unlock it. This pairing of the key to the lock is done simply by asking pair a key to the lock. You are not being told to use a specific vendor of magic keys. You are not being peddled only magic key vendor over another!
6. If you want to change the magic key paired to a lock, you can do so at anytime on your own as long as you are in possession of the current magic key.
7. And of course, you can have multiple magic keys paired to the lock, so that you can unlock with any of the keys.
8. When you use a key to unlock a lock, the lock can tell which paired key was used – you can give nicknames to the paired keys that the lock remembers. The lock will tell you which nicknamed keys were used to unlock it previously and when.
-----
Here's where I think passkeys went awry. They became yet another platform war. The OSes and browsers are supposed to be neutral and provide an unobtrusive prompt for user to pair a key or use a key, that's it. And the user should invoke a keyring against that prompt. If the keyring provider has features – like portability or non-portability of keys etc that's unique to each key ring provider and as long as the user is comfortable with it, everyone should be good with it. The prompt needs to be unassuming. Today it is very assuming and that's the problem!
thefz(2)
Lots of criticism in the article, some of it valid, none of it constructive.
Sure, there's UX problems as we're still trying to figure out what good looks like here. But in the absence of specific, concrete suggestions about how we improve usability for unphishable credentials, it seems that passkeys are a pretty good go. Perfect? No. Better than passwords? Undoubtedly.
Sure, there's UX problems as we're still trying to figure out what good looks like here. But in the absence of specific, concrete suggestions about how we improve usability for unphishable credentials, it seems that passkeys are a pretty good go. Perfect? No. Better than passwords? Undoubtedly.
I don't think it's the responsibility of the author to make any constructive input to the passkey problem. The point of the article is to show the valid shortcomings of this technology that a bunch of companies are attempting to force on users.
My workaround to allow passkeys to be reasonably usable is to use my password manager, just like the author of this article. This makes passkeys essentially the same as passwords.
At no point am I tying account access to a device, or series of devices, as this is ridiculous and unusable.
Passkeys as encouraged by the big companies are all about vendor lock-in than security.
My workaround to allow passkeys to be reasonably usable is to use my password manager, just like the author of this article. This makes passkeys essentially the same as passwords.
At no point am I tying account access to a device, or series of devices, as this is ridiculous and unusable.
Passkeys as encouraged by the big companies are all about vendor lock-in than security.
> I don't think it's the responsibility of the author to make any constructive input to the passkey problem.
Oh, it's not their responsibility, sure. But moaning about the UX without considering the trade-offs and decisions that got us to this point isn't very useful. Passkeys are badly implemented on some sites. So let's fix that.
> This makes passkeys essentially the same as passwords.
Passkeys in a password manager are fundamentally different to passwords. Try copying the passkey private key into your clipboard from your password manager.
> Passkeys as encouraged by the big companies are all about vendor lock-in than security.
The fact they prevent phishing is just a useful side-effect? This is veering into conspiracy theory territory.
Oh, it's not their responsibility, sure. But moaning about the UX without considering the trade-offs and decisions that got us to this point isn't very useful. Passkeys are badly implemented on some sites. So let's fix that.
> This makes passkeys essentially the same as passwords.
Passkeys in a password manager are fundamentally different to passwords. Try copying the passkey private key into your clipboard from your password manager.
> Passkeys as encouraged by the big companies are all about vendor lock-in than security.
The fact they prevent phishing is just a useful side-effect? This is veering into conspiracy theory territory.
It's not just some sites, the article goes into more detail than this, for example the biggest sticking point to me mentioned in the article is vendor and device lock-in. This is a recipe for getting locked out of your accounts and is far from a conspiracy theory. The only answer to this is create multiple passkeys on multiple devices/services OR use a password manager.
This is hardly the frictionless experience promised by passkeys. And it's perfectly valid to point this out. I don't care about the decisions and trade offs that got us to this point and not should I have to. If you want me to use a shitshow you designed the onus is on you to fix it, not me as the person you're attempting to force it onto.
This is hardly the frictionless experience promised by passkeys. And it's perfectly valid to point this out. I don't care about the decisions and trade offs that got us to this point and not should I have to. If you want me to use a shitshow you designed the onus is on you to fix it, not me as the person you're attempting to force it onto.
> Passkeys are badly implemented on some sites. So let's fix that.
It's not the obligation of the Ars writer to fix that. It is their obligation to give the system a solid try and report honestly about what did and did not work.
> Try copying the passkey private key into your clipboard from your password manager.
Yeah, something that's roughly equivalent to that is coming. Used to be that you were not permitted to export key material. Now you can. This will erode further as real-world use continues.
Oh, wait. It looks like secured-only-by-a-password access to passkey private key material is already possible, today:
"Q: Are stored passkeys included in Bitwarden imports and exports?"
"A: Passkeys are included in .json exports from Bitwarden. The ability to transfer your passkeys to or from another passkey provider is planned for a future release."
Quotes are via the "Passkey Management FAQ" section of this page: <https://bitwarden.com/help/storing-passkeys/>
It's not the obligation of the Ars writer to fix that. It is their obligation to give the system a solid try and report honestly about what did and did not work.
> Try copying the passkey private key into your clipboard from your password manager.
Yeah, something that's roughly equivalent to that is coming. Used to be that you were not permitted to export key material. Now you can. This will erode further as real-world use continues.
Oh, wait. It looks like secured-only-by-a-password access to passkey private key material is already possible, today:
"Q: Are stored passkeys included in Bitwarden imports and exports?"
"A: Passkeys are included in .json exports from Bitwarden. The ability to transfer your passkeys to or from another passkey provider is planned for a future release."
Quotes are via the "Passkey Management FAQ" section of this page: <https://bitwarden.com/help/storing-passkeys/>
The point of the article is that they are not actually better than passwords in a lot of ways that people actually want them to be better.
One of the primary, explicit design goals of webauthn is that they're not phishable. Passwords are phishable.
What are the other ways that people want passkeys to be better?
What are the other ways that people want passkeys to be better?
They want to share them across devices, sometimes even devices made by different vendors. They want to hand a passkey to a family member or friend. They want to not be concerned they will lose the passkey if the device they are on is lost. They want to understand what the passkey is actually doing for them when they log in, rather than it sometimes being both the username and password, sometimes just replacing the password, and sometimes becoming a sort of weird second factor thing. They want to know how they can change their passkey. The rollout of passkeys leaves a lot to be desired.
I don't disagree with you about the UX. It could be better. It could be worse. What's your proposal on what a better UX might look like (along with getting everyone to adopt it)?
> They want to share them across devices
I do this today on Bitwarden, Apple users do this today with Keychain. Who's the "they" here?
> sometimes even devices made by different vendors.
> they want to hand a passkey to a family member or friend
..... Why? What's the use case here?
Tying a credential to a single identity (and therefore, human) is another explicit design goal of webauthn. I seem to remember the original proposal was that locking a private key to a device in an unextractable, un-copyable way was an explicit benefit - if it can't be exported, then it can't be stolen/copied without the device also being stolen. This was softened with the purpose of allowing syncing amongst devices that already have a good story on sharing sensitive data, but this mechanism does not exist generically. There is no standard way, right now, that my iPad and Pixel device can share a private, sensitive piece of information without the help of a 3rd-party syncing provider. Without that, cross-platform credential sharing can't exist out of the box by default.
> They want to share them across devices
I do this today on Bitwarden, Apple users do this today with Keychain. Who's the "they" here?
> sometimes even devices made by different vendors.
> they want to hand a passkey to a family member or friend
..... Why? What's the use case here?
Tying a credential to a single identity (and therefore, human) is another explicit design goal of webauthn. I seem to remember the original proposal was that locking a private key to a device in an unextractable, un-copyable way was an explicit benefit - if it can't be exported, then it can't be stolen/copied without the device also being stolen. This was softened with the purpose of allowing syncing amongst devices that already have a good story on sharing sensitive data, but this mechanism does not exist generically. There is no standard way, right now, that my iPad and Pixel device can share a private, sensitive piece of information without the help of a 3rd-party syncing provider. Without that, cross-platform credential sharing can't exist out of the box by default.
My wife and I share passwords fairly regularly. Usually in a context where one of us is busy and wants the other to log into something they set up (e.g. to pay a bill), so the entire point is to not spend a few minutes going through an enrollment flow or whatever to give the other access (otherwise they'd just do the task). We may also not be in the same location when things like that come up.
Tying a credential to a single human is exactly not something desirable for a subset of users. Some married couples essentially act as a single person in most contexts (e.g. sharing an email address and/or phone number), which kind of makes sense; legally (in many states) the point of getting married is that everything becomes shared. The goal is to reduce friction around who owns/has access to what.
The real world obviously has different constraints, but works basically in this way. e.g. if I go to drop off/pick up a prescription for my wife, I just tell them her name, not mine. We use credit cards with the other's name all the time. etc.
> What's your proposal on what a better UX might look like (along with getting everyone to adopt it)?
Passwords, obviously.
Tying a credential to a single human is exactly not something desirable for a subset of users. Some married couples essentially act as a single person in most contexts (e.g. sharing an email address and/or phone number), which kind of makes sense; legally (in many states) the point of getting married is that everything becomes shared. The goal is to reduce friction around who owns/has access to what.
The real world obviously has different constraints, but works basically in this way. e.g. if I go to drop off/pick up a prescription for my wife, I just tell them her name, not mine. We use credit cards with the other's name all the time. etc.
> What's your proposal on what a better UX might look like (along with getting everyone to adopt it)?
Passwords, obviously.
> My wife and I share passwords fairly regularly. Usually in a context where one of us is busy and wants the other to log into something they set up (e.g. to pay a bill), so the entire point is to not spend a few minutes going through an enrollment flow or whatever to give the other access (otherwise they'd just do the task). We may also not be in the same location when things like that come up.
Mine too! We simply register multiple passkeys under the same "account" for a service and we can both log in as the same identity. Have I missed something? Why is this hard?
> Passwords, obviously.
Passkeys are trying to solve the phishing problem. I guess pretending that the problem doesn't exist is also some type of solution, but I don't think it's a very good one.
Mine too! We simply register multiple passkeys under the same "account" for a service and we can both log in as the same identity. Have I missed something? Why is this hard?
> Passwords, obviously.
Passkeys are trying to solve the phishing problem. I guess pretending that the problem doesn't exist is also some type of solution, but I don't think it's a very good one.
> Have I missed something? Why is this hard?
Yes,
1. We don't set up accounts together. One just does it, and generally password sharing comes later at some inconvenient time (which is why they're asking the other person to deal with it). Until you can easily copy/send a passkey through an IM, they are less usable than passwords in important ways.
2. Passkeys don't even work on our desktop computer (Linux/Firefox), making them completely unusable.
I'm not pretending phishing doesn't exist, but for us, it creates problems while not solving any problem we have. I'm not really worried about phishing. Autofill and bookmarks already basically mitigate that for us. It's not like I'm going to click on a reddit link that takes me to "fidelity" and think "oh good idea I should check our brokerage".
Yes,
1. We don't set up accounts together. One just does it, and generally password sharing comes later at some inconvenient time (which is why they're asking the other person to deal with it). Until you can easily copy/send a passkey through an IM, they are less usable than passwords in important ways.
2. Passkeys don't even work on our desktop computer (Linux/Firefox), making them completely unusable.
I'm not pretending phishing doesn't exist, but for us, it creates problems while not solving any problem we have. I'm not really worried about phishing. Autofill and bookmarks already basically mitigate that for us. It's not like I'm going to click on a reddit link that takes me to "fidelity" and think "oh good idea I should check our brokerage".
> Passkeys are trying to solve the phishing problem.
They won't.
AIUI, their solution for this was to refuse to export the key material from its container. Now, they're allowing (or maybe "allowing") trusted third parties to copy that key material to back it up. I predict that within another couple of years, there will be a standard way for anyone to get that key material, which (from what I gather) makes their phishing-protection scheme no better than what password managers have been offering for a long time now.
EDIT: It looks like at least one major password manager will just export your passkey private keys wholesale. I guess this exciting future is here now. Details here: <https://news.ycombinator.com/item?id=42555371>
They won't.
AIUI, their solution for this was to refuse to export the key material from its container. Now, they're allowing (or maybe "allowing") trusted third parties to copy that key material to back it up. I predict that within another couple of years, there will be a standard way for anyone to get that key material, which (from what I gather) makes their phishing-protection scheme no better than what password managers have been offering for a long time now.
EDIT: It looks like at least one major password manager will just export your passkey private keys wholesale. I guess this exciting future is here now. Details here: <https://news.ycombinator.com/item?id=42555371>
> Why? What's the use case here?
Tech support for relatives. Accessing accounts from different machines. Joint access for family members and friends. Emergency access when a phone or dongle breaks down or gets lost.
Tightly device-tied authentication mechanisms are fundamentally out of touch with the real world.
Tech support for relatives. Accessing accounts from different machines. Joint access for family members and friends. Emergency access when a phone or dongle breaks down or gets lost.
Tightly device-tied authentication mechanisms are fundamentally out of touch with the real world.
> > they want to hand a passkey to a family member or friend
> ..... Why? What's the use case here?
This is the problem, if you can't even imagine this case. Someone in their 70s who isn't great with computers would likely be very happy to share their password with a tech-savvy child who can do some things for them. Passwords make this really easy, and you can even register a second MFA that goes to the child's phone/TOTP.
> ..... Why? What's the use case here?
This is the problem, if you can't even imagine this case. Someone in their 70s who isn't great with computers would likely be very happy to share their password with a tech-savvy child who can do some things for them. Passwords make this really easy, and you can even register a second MFA that goes to the child's phone/TOTP.
You don't even need to be in your 70s or not tech-savvy. Password-sharing happens frequently between spouses, children/parents, friends and probably a lot of other cases.
I share accounts with my spouse using passkeys just fine. We just register our own passkeys. shrug.
Okay, you've got an elderly parent on the phone. How do they register a passkey for this website they've signed up to and don't know how to use?
[deleted]
> What's your proposal on what a better UX might look like (along with getting everyone to adopt it)?
The current passkey implementation is: Your google/apple/microsoft cloud account lets you log into websites without a password, using a 'keyring' of 'passkeys'
But we already had countless websites with a "log in with google" button, for users who want to authenticate using their cloud account, and skip entering a password.
So they could have just kept that... exactly how it was?
The current passkey implementation is: Your google/apple/microsoft cloud account lets you log into websites without a password, using a 'keyring' of 'passkeys'
But we already had countless websites with a "log in with google" button, for users who want to authenticate using their cloud account, and skip entering a password.
So they could have just kept that... exactly how it was?
The analogy is similar to swiping your credit card versus using Apple Pay. With “login using Google/Apple”, you are submitting the username and password which could potentially be harvested by malware or a key logger. With passkey/Apple Pay, you are submitting a one time token that has no value in the Dark Web.
> Why? What's the use case here?
I had a tele-medicine visit scheduled regarding my son. When I logged in, it said I wasn't authorized. My wife had no problem. So she gave me her password. We both logged in as her. Everything was fine. I'm sure this was some record-keeping issue, but if we had been using passkeys, I just would not have been able to participate.
I had a tele-medicine visit scheduled regarding my son. When I logged in, it said I wasn't authorized. My wife had no problem. So she gave me her password. We both logged in as her. Everything was fine. I'm sure this was some record-keeping issue, but if we had been using passkeys, I just would not have been able to participate.
I mean I like them in theory but they should just be passwords you can't easily copy from your password manager. You can export them, which I'm sure someone will trick people into doing, but that's somewhat different from being tricked into pasting ul0vek1tt3ns into legitimateapple-support.info.
As for sharing passkeys: never grabbed a friend's Netflix account? Had to log into your kid's college application page to confirm your income? Sign up for an appointment for your elderly parents? This is a thing people actually need to do, and value more than avoiding being phished. Believe me. It's not worth abandoning for "ok there is a possibility someone can be phished if the key material isn't protected by a hardware key and three layers of DRM".
As for sharing passkeys: never grabbed a friend's Netflix account? Had to log into your kid's college application page to confirm your income? Sign up for an appointment for your elderly parents? This is a thing people actually need to do, and value more than avoiding being phished. Believe me. It's not worth abandoning for "ok there is a possibility someone can be phished if the key material isn't protected by a hardware key and three layers of DRM".
> ..... Why? What's the use case here?
Others have pointed out use cases, but please step back for a second. Sharing passwords is extraordinarily common for a variety of legitimate reasons.
Others have pointed out use cases, but please step back for a second. Sharing passwords is extraordinarily common for a variety of legitimate reasons.
And why do they do it? What are they trying to achieve?
I'd guess that they most likely want multiple people to be able to access a single account. Passwords are forced to be shared because a password is typically implemented as a single credential - there's one valid password for that account.
This is .... not true for passkeys. If you want two people to access the same account, they both add passkeys to that account.
Sharing passwords happen because of a property of passwords. It's not some fundamental requirement that people have. What people want is shared access.
I'd guess that they most likely want multiple people to be able to access a single account. Passwords are forced to be shared because a password is typically implemented as a single credential - there's one valid password for that account.
This is .... not true for passkeys. If you want two people to access the same account, they both add passkeys to that account.
Sharing passwords happen because of a property of passwords. It's not some fundamental requirement that people have. What people want is shared access.
How do you bootstrap the system? Presumably your spouse/partner/friend and you use different computers? With 1password I can just share passkeys in the UI.
I just wanted a standard data exchange interface between my browser and my preferred password manager, so that my password manager didn't have to try to emulate a human being typing or pasting a password.
That way the password would only "live" in the password manager and wouldn't need to even be easily visible to me. I almost never care what the password actually is.
But it would still be a password so compatible with most sites as-is, and easily backed up and restored on new devices.
That way the password would only "live" in the password manager and wouldn't need to even be easily visible to me. I almost never care what the password actually is.
But it would still be a password so compatible with most sites as-is, and easily backed up and restored on new devices.
> Passwords are phishable.
Passwords auto-filled by a browser extension are not phishable.
Passwords auto-filled by a browser extension are not phishable.
“Huh, wonder why that didn’t autofill this time.” Person copy/pastes password from manager into phishing site.
Browser extensions do not prevent copy/pasting, or typing in, passwords. In contrast, there is no way to copy/paste or type in a passkey if the phishing site fails the key check.
Now you might say that YOU have the discipline to never do this. And it might be true. But that’s not the same as saying autofill passwords are not phishable.
Browser extensions do not prevent copy/pasting, or typing in, passwords. In contrast, there is no way to copy/paste or type in a passkey if the phishing site fails the key check.
Now you might say that YOU have the discipline to never do this. And it might be true. But that’s not the same as saying autofill passwords are not phishable.
What stops the user pasting their password out of their password manager into a random evil site? Auto-fill isn't infallible.
This isn't a controversial topic, the data is pretty unambiguous. If you give humans a secret they can put in their clipboard and train them to enter it into text boxes, some fraction of them will send their credentials to the wrong people.
This isn't a controversial topic, the data is pretty unambiguous. If you give humans a secret they can put in their clipboard and train them to enter it into text boxes, some fraction of them will send their credentials to the wrong people.
The same thing that stops the user from going through an account recovery flow to enroll an attacker's key. Such flows are of course more necessary in a world where you can easily lose/damage the only place where your keys are stored.
Maybe we don’t actually need perfect solutions.
"Maybe" is not a viable justification for a position.
I am being flippant. Obviously my position is that perfection is a harmful thing to strive for.
We're not aiming for "perfect", we're just trying to make some progress on the phishing problem.
The irony here is that many of the complaints in this thread seem to be complaining about how imperfect passkeys are. No-one disagrees that they're imperfect!
The irony here is that many of the complaints in this thread seem to be complaining about how imperfect passkeys are. No-one disagrees that they're imperfect!
Yes, and passkeys generally help. But your concern upthread was that any mechanism that lets users share or export passkeys (or other authentication material, such as passwords) allows a user to be phished. Basically, the very fact that this is somehow accessible means a user can be tricked into disclosing it. This is correct, but my point is that perfection in that area necessarily means that a lot of things that are useful (some of which have been shared in sibling threads) are now impossible. So we should not actually aim for perfection on phishing, but just to make improvements where possible.
This. In other words, password managers have all the benefits and none of the drawbacks of passkeys. And passkeys require a password manager anyway, so why are we trying to switch?
They don't have the benefit of not being pastable into a phishing site.
Should password managers make it impossible to copy the plain text of the password? Thats the only way to make this truly not phishable
If you show it on a screen, someone will read it out and type it into a website. We don't need to guess at this, it happens a lot in the real world.
No matter how many UX barriers you put in place, an exportable credential will be handed over to an attacker by an unwitting user at some point.
No matter how many UX barriers you put in place, an exportable credential will be handed over to an attacker by an unwitting user at some point.
I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc. I already have a universal solution for credentials: 1password, which is cross-platform. With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer. But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.
Like with many other solutions, the current approach with passkeys is designed for an imaginary "user in vacuum" model each company dreams about, where people are 100% into one ecosystem, forever.