iCloud Keychain is required on macOS to create passkeys in Apple Passwords (which uses iCloud Keychain to securely sync them). Apple Passwords is the default credential manager in macOS (similar to Google Password Manager on most Android devices). If you want to save to another credential manager (app) on your Mac, you need to install it and enable it. If you don't have another credential manager on your Mac, that is why you can't save a passkey on your Mac and are given the option to save to another device.
No, you can't just use whatever passkey manager that you want.
I use Safari, Chrome, MacOS, a Google Pixel phone, and 1Password. I have passkeys in 1Password, but it's a crap shoot if I'm able to login on a device.
Chrome wants me to use Google Password Manager. There's no option in chrome://settings to set 1Password as my passkey manager. If I try to use a passkey to login to GitHub Chrome pops up a modal that lets me choose between iCloud Keychain, Use a phone or tablet, or USB security key. There's no option to use a different credential manager.
Safari wants to use my iCloud Keychain. There's no option in MacOS Settings to set 1Password as my passkey manager. If I try to login to GitHub I get an option to Scan QR Code or Use Security key. There's no option to use a different credential manager.
My Pixel wants to use Google Password Manager. There *is* an option in Pixel Settings to set 1Password as my passkey manager, but it doesn't work in Chrome. All I can do it select "use another device" and it shows a QR code. There's no option to use a different credential manager.
Essentially every OS and browser thinks I want to use a phone for my passkey, and this is exactly the situation that I and everyone else is bothered by. I do not want to tie my login credentials to a phone that can be lost/stolen/bricked and will be replaced in several years.
So no, you can not use your own credential manager.
Great examples, exactly what I'm saying. And every one of these (browsers, OSes, phones, etc) has strong incentives to only offer its own password manager.
You wont' typically see a setting in your browser, because credential managers are designed to operate at the system level, so that your credentials aren't "stuck" in your browser. This is why you don't see an option in Chrome settings. You can, however, disable Google Password Manager in Chrome settings, as it is a Chrome feature.
It's notable that several of the claims on that page conflict with the other info in both the OP article and the follow-on.
As for choice as the user, it's a choice "for now"... and only for users who understand all of these details (which seems unlikely).
Personally, my observation is that if one tries to properly configure 2FA with any major website lately (no, I don't mean AWS console), the level of "your choice" and properly implemented security has actually gotten worse...
Much like you could use any AOSP fork to run banking applications... until you couldn't. But hey, at least there's an explainer website[0] that completely glosses over this detail.
[0]: One great bit of environmental storytelling is the "Made with <3 by the passkey community" in the footer. "Passkey community" of course means timcappalli with minor contributions from two others. You might remember him from https://github.com/keepassxreboot/keepassxc/issues/10407#iss....
Lot's of additional great information for consumers and prosumers at whatarepasskeys.info. Many of the questions that are constantly discussed in these comments are answered in the FAQ and content.
Contributions and feedback are welcome! GitHub link is at the bottom of the page.
Why are passkeys designed in a way that I can't copy the private key as text to import into whatever password manager I want, even as an advanced user?
You can. Choose a credential manager that offers that feature.
I just don't think that's a good idea for most users. Imagine an older relative being coaxed into exporting all their passkeys in plaintext and uploading them to a website.
There's seemingly no password manager that lets me export the passkey as plaintext, at least not on a Mac. At best I can hand off to another app, which only works from Keychain and nothing else, and can only go to a preset approved list of apps like 1password. iPhone situation is a bit better, at least I can transfer from 1password to other things, but again it seems like a whitelist and there's no way to just get a csv.
Besides all that, the standard supposedly supports types of passkeys 1. bound to the device (not a security key) that cannot be handed off at all, or 2. can only be used in certain apps. I'm guessing the first case is more for corps that only want employees logging in with issued corp devices, but why the second one?
Everything has conditions, which is why I'm wondering why this isn't just an unconditional "yes, it's your key, do whatever you want."
2FA exists because defense in depth. Even if passwords weren't phishable, it can still be handy to defense in depth that a person is who they say they are by checking multiple factors ("something you know", "something you are", "something you have").
Passkeys largely meet 2FA requirements by themselves because they are "something you have" (its stored on a device you own) and require "something you know" (device PIN) or "something you are" (biometric unlock) to use.
I would say its something you have when it’s hardware backed, including secure enclave/pin/face id, but a cloud sync’d password manager isn’t necessarily that, though, again still a better situation than a phished password.
It's still not quite something you know or you are, so it is a different factor, even if we can quibble on if it is more weakly "something you have" when not hardware specific.
It moves the attack surface to password managers, which is arguably a better situation than phishing. I'm skeptical that the war is over, though. I have no proof to back this up as phishing is the low-hanging fruit today, so the numbers 'largely' back you up. I personally include device compromise in my threat model and I'll concede that may be overdoing it for the average person.
Asking that services require you to encrypt your backup file by default to protect against local malware or malicious access is certainly not "The people behind passkeys do not like...allowing you to export your passkeys".
Hey Hacker News! Over the past few years, most posts about passkeys have spiraled into endless debates with hundreds (and in some cases thousands) of comments. I've ventured into many of these trying to provide some context from the development of passkeys and some ecosystem perspectives. Two big observations were that there aren't any vendor neutral resources for regular users to help understand passkeys, and many sites/apps which use passkeys don't provide a lot of guidance or education to users.
A few of us from the passkey developer community have teamed up to create a new consumer-friendly site about passkeys, with easy to understand explanations and illustrations, frequently asked questions, and some details on picking a good credential manager. There's also an advanced toggle which adds some technical details to each section (and in the future some more technical FAQs and sections). Much of the content is based on questions and comments from this community as well as Bluesky, the Fediverse, Reddit, and direct user engagement.
The goal is for this to be a living site, with constant tweaks based on community feedback. You can create issues and/or PRs on GitHub or just submit general feedback via the web form (both are linked at the bottom of the site). The site has no corporate backing or influence, and all feedback is welcome. Scathing critiques or praise. Just please be respectful.
We're also eagerly looking for non-native English speakers to review translations for the current future localized versions of the site.
If you run a site that offers passkeys, please consider adding a link to your docs, and even your passkey enrollment screens.
reply