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.
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.
> 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.
>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).
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.
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.
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.
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.
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 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.
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.
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.
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)
> 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.
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. :-)
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.
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.
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.
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.
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’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.
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 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 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?
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.
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 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.
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.
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".
> 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.
congrats. your problem is solved in the two or three places that actually allows or even implements any logic from N passkeys. on most places that will just give you a new account or wipe the first key.
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).
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)
>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.
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.
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.
”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.
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.
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 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!
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.
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.
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 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.
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.
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".)
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 :-(
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 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.
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.
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.
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.
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.
> 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:
> 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?
> 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.
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...
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.
> 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!
> 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.
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.
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).
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.
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".
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.
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.
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.
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.
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.
> 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.
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).
> 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.
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.
> 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.
>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.
> 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.
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.
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.
> 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.
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.
> 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.
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'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.
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 :(
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.
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.
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.
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.
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.
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.
https://en.wikipedia.org/wiki/Podcast says "Podcasting is the preparation and distribution of audio or video files using RSS feeds to the devices of subscribed users."
Spotify does not have a trademark on rss podcast delivery. RSS feeds have historically been the primary delivery method for podcasts and it long predates Spotify and the JRE. Many of the most popular or historically significant primarily used RSS: Serial, This American Life, Stuff You Should Know—the list goes on and on. Some podcasts are distributed via video, but even many of those also have a corresponding rss feed for the audio version.
I didn't claim it had a trademark, but if you literally skipped entirely over the comment I was responding to: he quoted the Spotify docs for their podcast APIs as an argument why podcasts are RSS/MP3
And his second link literally confirmed how entirely wrong his own claim was, within literally the first paragraph. Which you seem to have skipped over too....
So where does that leave us? With now two very confused commentors that seem to be unable to read, hence my previous quip about reading comprehension
In case your genius mind wasn't able to comprehend this amazing concept: the technical implementation of most podcasts in 2000s does not define the concept of a podcast.
Yes, once upon a time, that was the most common way podcasts were distributed. It however wasn't the definition of the word "podcast".
Did you get that, or was that once again too complicated for you?
That is definitively what they were when the term "podcast" was new and I was trying to figure it out - and in any case this seems like rather pointless hairsplitting.
I'm not going to dictate MP3, but yes: podcasts absolutely are an audio file pulled from an RSS feed. Your description covers some podcasts, but not every podcast has video (which should be entirely optional if it's there at all, and frankly makes it less of a podcast in my opinion), and many go through some pretty heavy editing, even if just to balance audio levels, prune dead conversational branches, and remove filler words or dead air.
You're being pretty abusive in this thread, which in turn has provoked others to be abusive, which is why the guidelines specifically on comments say things like this
- When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
- Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
- Please don't fulminate. Please don't sneer, including at the rest of the community.
You'll see one of your most abusive comments has been flagged. You'll find that happening more and more to you if you continue to comment like this.
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.
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.
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).
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.
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'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).
> 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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.)
> 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.
>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.
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.
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".
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 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?
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.
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.
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.
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.
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.
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?
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
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.
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).
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.
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.
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 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.
> 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?
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.
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.
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.
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)
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.
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.
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!!!)
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."
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.
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.
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.
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.
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.
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.
> 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.
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?
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).
> 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).
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"
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.
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.
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.
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.
"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.
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.
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'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.
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!
The article is quite good, and as someone who uses passkeys I feel it. So far I've only been using them as a convenient alternative to passwords (passkeys go right next to passwords in 1password), and I plan to keep using them that way.
One problem with your proposed title is that "etherogenoeous" doesn't seem to be a word. Even it is, approximately no one is likely to know what it means.
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.
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.
> 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.
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.
> 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."
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.
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)?
> 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.
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>
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.
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.
> 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 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.
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".
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.
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.
“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.
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.
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.
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!
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?
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.
reply