The author still has one last misconception about passkeys, namely that if you lose a passkey, you have "no recourse."
People wrongly think passkeys are like Bitcoin wallets, where losing them means there's absolutely nothing you can do, your account is simply lost forever.
Losing a passkey is exactly like losing your password, which is to say, that for 99% of services, you can reset your password/passkey really easily. There's a prominent "Reset Password" button right on the login form. It sends you an email or an SMS, you click it, and it lets you reset right then and there. You can reset your passkey in exactly the same way.
It is not that easy to reset if you lose your password to your Apple, Google, Facebook, etc. They all have a bunch of factors that they use to authenticate you if you reset your password, and they don't even document which ones they use.
So, if you care about those accounts, you've got to make sure you have backup access. They all let you generate and print "backup codes" (emergency passwords) and store them in a fireproof safe or a literal bank vault. Do that!
As everybody knows, you can't store all of your passwords in a password manager. You need something outside of the password manager to login to the manager itself. That's why 1Password/LastPass is called that; you still need one last password that you keep and manage yourself.
That's true of passkeys, too. You can login to Google with passkey, but if Google is your password manager that stores your passkey, you need something else outside of Google's password manager to login to Google. Whether it's a password, a backup code, a YubiKey, whatever, you need one more thing to login to Google, ideally more than one, so you can back it up and keep it safe.
Pre-passkeys, was this lockout issue a true issue with apple and google accounts? Or have passkeys added a general lockout issue that didn't exist before? Also passkeys in their current implementation are not possible to back up or export yourself, unlike passwords in the past.
Security engineers are prioritizing preventing key copying over lockout issues, unilaterally, on literally billions of people. It improves their metrics internally, at the cost of an externality on the entire world. This kind of stuff invites odious regulation as more and more stories of lockout with no recourse surface.
And unlike passwords, there is no good provider migration story. There is a roach motel issue. Yes it is being 'worked on', but passkeys and such have been out for many years, the willful denial whenever you ask people running these standards about these issues is incredibly irritating. The fact they tend to avoid questions about this like politicians decreases trust in the motives of such standards.
> unlike passwords, there is no good provider migration story
I'm curious what the "good provider migration story" you're referring to here for passwords is?
Password managers by-and-large haven't agreed on a standardised interchange format for import/export - a few of them have some compatibility helpers for importing from specific popular competitors but they're all in different formats, no consistent formats.
The above goes for passkeys as it does passwords - import/export will include your passkeys - so I don't see much difference in the provider migration story.
On the other hand, the FIDO Credential Exchange Format does solve the above problem (if/when providers choose to adopt it), so passkeys are at least further along the path of creating a "good provider migration story" than passwords ever were.
I agree. I use passwords with TOTP whenever possible. Passwords in a locally stored database (such as KeePassXC) can be easily shared. TOTP using Google Authenticator can also be easily shared, not just with my partner, but also among my own devices. Right now I see this as a much better, simpler, and much easier to understand option.
BTW, the "easier to understand" is a big feature. Passkeys seem to be complex; just look at all the arguments about them in these comments. And where there is complexity there is vulnerability.
1Password family plan, and I assume similar cloud password managers, let you organize passwords/TOTP/Passkeys into vaults, and you can put credentials you want to share with other family members here.
You can store passkeys in a password manager where they're either in a full-time shared config or there's some configuration that allows access if something happens. (e.g. Emergency Kit for 1Password, legacy contact for Apple account, etc.)
> Pre-passkeys, was this lockout issue a true issue with apple and google accounts?
Yes, absolutely. I have a second Google account I created and lost the password to. I can't reset it because it wants to know the exact month I opened it. I don't even know if it was 2012 or 2016, I'll never guess the month.
Yes. People have complained about the difficulty of Google or Facebook account recovery and how they need to make it easier and more accurate for ages. You could search hn for "password reset" or "lost password" and you'll find tons.
The primary credential a user relies on for logging in (whether it's a password or a passkey) is pretty unrelated to the the "lockout issue". The lockout issue is really the age old question of: what happens if I can't do a normal email-based account recovery flow (aka "I forgot/lost my password/passkey").
No, passkeys haven't added a new general lockout issue, because Apple, Google, etc. don't allow you to create an account where you can only login via passkey with no external authentication factor. They require you have something outside the Google account, whether that's a password, a hardware key, etc.
People keep falsely imagining that Google is setting people up with passkey-only accounts, with no way to backup their login credentials. Gosh, wouldn't that be terrible?
That would be like 1Password letting you create a passkey-only account with no password, storing the only passkey in 1Password. The whole idea makes no sense. 1Password doesn't do that, and neither does Apple, Google, Microsoft, etc. (We can all imagine them doing something that stupid, but, it turns out, they don't.)
Pre-passkeys, the most common lost-credential scenario was creating a fresh Gmail address on a new device (an Android phone) with a password and forgetting both your Google password and your password for your cellular-phone carrier (AT&T, T-Mobile, etc). Your Google password would be stored locally on your phone and in Google's cloud, but when you lose your phone and forget your passwords, no backups remain.
At that point, you're pretty much screwed. Google can't email you a reset-password link, because Gmail is your email. Google can't send you a 2FA SMS until you get a new phone with the same number, but you can't convince AT&T to do that, because they want to send a reset-password link to your email, which you don't have, or SMS to your phone, which you don't have.
(The cellular carriers don't even allow you to show government ID at a physical store. They don't allow you to take over a phone number that way, because people could then threaten/bribe a T-Mobile store representative to falsely claim that you presented valid government ID, taking over other people's accounts. If you walk into a store, they'll just put you on the phone with customer service, where they'll insist that you provide your AT&T password, or reset your password via email or SMS. If you've lost your email and your phone and all your passwords, you're completely out of luck.)
If Google allowed you to create a passkey-only account, with no SMS 2FA and no way to backup your passkey, that would be even worse.
But, luckily for all of us, they don't even allow that, and they're certainly not pushing it unilaterally on billions of people.
This is not a feature of passkeys, this is a feature of each and every individual provider building their own unique reset flow.
Not every provider does this correctly. Just yesterday I saw someone complaining on mastodon about their passkeys being locked and requiring a phone call to get reset.
Passkeys are exactly as resettable as passwords, which depends on your provider actually implementing things correctly.
tbh I think it's safe to claim they're strictly inferior to passwords, though in almost all cases they're literally identical (as you point out).
e.g. that phone call case: some places will tell you a temporary password (over the phone) to enter next time, and then you come up with a new one when you log in. there is no equivalent flow for passkeys, because you can't enter them by hand. a site could of course build that for passkeys (like a temporary password with special UI for entering it), but literally every site with passwords can do that by default, it just needs a general admin UI which almost always exists.
(most I've encountered will email you a temp password, and in principle you could email a temp passkey too... but that doesn't work by phone / for manual entry, and is there a spec on that file format? I don't think so? in your password manager right now: is there a place to manually import a passkey for a website? half of mine don't have one for passkeys, but every single one I've ever seen has a way to manually enter a password)
> but literally every site with passwords can do that by default, it just needs a general admin UI which almost always exists.
Most sites/systems that are designed for security won't have such an admin UI - passwords should generally not be handled in a way where anybody other than the user is ever able to know what they are.
"I can erase a securely hashed password and set a new one" is very common and generally seen as safe, and does not at all require being able to "know what [the current password is]".
Apple and Google often store your other 99% of passwords and passkeys, so losing this is actually more important than losing the 99%. I take your point but saying 99% have reset services when the critical 1% may never be recoverable without posting to HN is an important point.
For those you add recovery e-mails. You can easily have a Google, Microsoft and Yahoo e-mail so having access to at least one means you can recover the rest. Yes, this increases your attack surface, but the chances remain miniscule.
Just as a note: for E2EE services that use your password to decrypt your key to decrypt your data, a recovery email often recovers your user account BUT not your data (so you may get access to a blank account). It is perfectly possible to lose access to your data, that may include the rest of your passwords, if you have not set up other recovery methods which can actually decrypt your encryption keys, and rely on a recovery email or phone.
Also, just so I'm clear, there's no requirement to share passkeys. Or even have passkeys enabled on all devices, right?
If I log in to a site from my machine, and set up a passkey, but then log into that site from another machine, it'll just see no passkey present and ask for my password, yes?
A passkey is a local password on a device that could be shared through all the password manager gymnastics, but its not required as I understand it.
That’s true for all accounts that i’ve been using (Google, Apple, Microsoft).
Passkey generated on a device can only change login flow for this one specific device. If you don’t synchronize passkey to other devices or if you do not generate passkey on other device, then login flow is different for other device. You need to enter password.
Imo it would not make any sense if it was different.
I think there are passkeys that can be migrated/synced between devices, and device-bound passkeys that can't. I do save passkeys on my password manager and use them across devices, but I am pretty sure I have had passkeys that I could only use from a specific device. Not sure though, it feels a bit confusing.
Yes, that's right. It might also make sense to generate multiple passkeys for an account. For example, a separate one for logging in from Apple devices.
in that case, passkeys are pretty useless considering that they can be bypassed by the other factors they were designed to eliminate in the first place.
Sure I'm super secure using a passkey.... except that there's always a "try another way" option on the login screen. Which defeats the purpose.
Vendor lock-in a serious concern. Just reading through this KeePass issue again and seeing how much pressure the industry is trying to exert to prevent the users from being able to export their own private keys should be concerning. I come back to this discussion every time I see someone arguing in favor of passkey adoption.
>The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers
Hi! I'm the commenter on that post that keeps being brought up!
I don't think requiring an encrypted backup (with a key or secret that YOU control) by default is "preventing users from being able to export their own private keys".
Hi! I have no issue with having the backup being encrypted by default, except the discussion returns again and again to disallowing any cleartext export, even when specifically requested by the end user.
And on a separate note, I fundamentally disagree for political reasons with the idea that the websites should be able to block specific passkey providers.
You say "requiring by default". That makes no sense in this context (or most) - you can either require something (which is not "by default") or you do not (at which point you can encourage something as strongly as you like, but it's still not required).
The github issue is quite clear about "requiring", not "by default", which is a restriction on what someone does with their own data. Particularly since AFAICT there is still no spec for data exchange over flat files. CXP is a probably-reasonable more-safe option to encourage, but it really shouldn't be the only option.
(arguably CXF only defines non-encrypted files, since it doesn't even recommend encryption options or provide a way to communicate what was used, except to say that it "MUST" encrypt or coordinate over CXP)
1. Passkey prompts asking if I want to use a phone or security key when I only have one (or neither!) registered. The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered.
2. Passkeys should have had the portability and flexibility that ssh keys have from the start. Making it so your grandparents can use public key cryptography and gain a significant advantage in securing their accounts in a user friendly manner should have been the priority. Seems like vendor lock-in was the goal from the start.
>The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered.
I disagree. It is very annoying when some service fails to show an option on the grounds that I can't use it. It makes it difficult to resolve problems. If the option is just missing, I have no way to tell whether the company doesn't provide the option, whether the company made some sort of mistake (they can't provide an email option because they lost my email), whether I made a mistake, or whether the company just has a bad UI that tries to hide the option. And don't forget the situation where I tried to google online for some help in using the UI, I found a 6 month old Reddit post showing the option, and I can't figure out if the company changed the UI in the past six months.
They should show it greyed out with a note "no key of this type registered".
That’s fair. I just meant that during logon, it is annoying to have to click through an additional prompt that doesn’t apply. But I can see where if there was an issue showing what all the options could be and if they are enabled or unavailable or you want to set it up, would be more beneficial than not.
On Mac with the security key you can just press the button on the security key before choosing a path. It only looks like a required extra step but in practice it is optional.
> Seems like vendor lock-in was the goal from the start.
Exactly. The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them. The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials. You can go from one passkey vendor to another, but you're always locked in to one passkey vendor or another.
Any credential system that makes it impossible to write something down on a piece of paper, take it to a new computer, and login to a website is just a gateway to vendor lock-in. You can manually manage your own ssh keys but for some reason not your passkeys.
As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. [EDIT: Obviously I'm talking about built-in support. I'm well aware of third-party software, so everyone can stop replying to this now, please!] You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
The passkey vendors took some good theoretical ideas, such as site-specific credentials and public-key cryptography, and totally mangled the implementation, making it hostile to everyone except themselves.
This is not true - browsers including Safari support passkeys managed by third-party password managers.
I'm using 1Password with browser extensions for Safari and Chrome on macOS and iOS and it works seamlessly with my passkeys, which are not stored in iCloud Keychain.
> you're always locked in to one passkey vendor or another.
> This is not true - Safari also supports passkeys managed by third-party password managers.
I think you know what I meant and are just being pedantic here for no good reason.
Do you think I'm unaware of 1Password? I don't want to use 1Password any more than I want to use iCloud Keychain.
Technically, pendantically, Safari "supports" anything that third-party Safari extensions support. I'm a Safari extension developer myself. But this is totally different from how Safari supports the use of passwords, which is all built in, requires no third-party software, can be local-only, allows plaintext export/import, etc.
Reading the cfx spec [1], the raw private key is exported as a base64 encoded der. I don't understand what your concern is here. It appears that any cfx export file is not tied to a specific service to service import path, but can be imported into anything, or just used locally with self written tools.
This is merely the exchange format between credential providers, which is encrypted and gatekeeped by the credential providers. None of this is exported to users.
OK I see what you mean. Having the ability to switch between vendors but not the ability to export your data locally (e.g. as plaintext keys) is a new meaning of "vendor lock-in" I hadn't considered before.
Yes. User freedom is not all-or-nothing. There are degrees, and the tech companies are coming up with fiendish new ways to lock away your data from you. So in the case of passkeys, you can technically move your data between vendors, though that can be quite inconvenient as the submitted article mentions, but nonetheless every vendor locks away your data from you, and most vendors have a financial incentive to keep your data away from you, so that you have to pay for the services.
Once "secure credential exchange" becomes supported by commercial credential managers, what's to stop someone implementing an open source password manager that implements the standard and allows local export in plaintext?
Passkeys relying parties can block providers. Tim Cappalli threatened the KeypassXC developers so.[1] The restrictions demanded now do not restrict user freedom significantly arguably. But the incentives and capabilities are clear.
OK but you'd still be able to use the open source "password manager" to export the keys - which solves the issue lapcat raised in this thread - even if relying parties blocked it for authentication, which would be a separate issue.
Someone could develop a "passkey export tool" purely for the purpose of doing credential exchange then local export.
Or are you saying the credential exchange process itself could block providers?
You misunderstood lapcat I think. They wanted Passkeys stored locally exclusively. And they wanted to be able to use them. The issues are not separate.
Not sure how stating that my (an individual) opinions on a topic are evolving is interpreted as "threatened the KeypassXC developers".
If you've been following along, you'll have seen that I am actually one of the biggest advocates of the open passkey ecosystem, and have been working really hard to make sure all credential managers have a level playing field.
Always happy to chat directly if you have concerns!
The threat you relayed was more serious than the threat you made. But it is a threat when a person with influence suggests they may support a punishment.
The biggest advocates of an open ecosystem say attestation should be removed and no one should adopt Passkeys before. Is this your position now?
The concerns were clear I thought. I would be happy to discuss this publicly.
Not really. The attestation model defined for workforce (enterprise) credential managers/authenticators doesn't really work in practice for consumer credential managers.
Avoid weasel words please. Is it possible in theory to use attestation or any other Passkeys feature ever to prevent a user to use any software they chose with any service they chose?
In theory any code could be written at any time that does something good or bad. Sure.
But in reality, the people who actually work on these standards within the FIDO alliance do not want a world where every website/service makes arbitrary decisions on which password managers are allowed. That would be a nightmare.
This is obviously kicking the can down the road, but I "solve" this problem by storing passkeys in a third-party credential manager that supports them. That way I can use them on any device that I've installed the client app or browser extension on. I have this working on Fedora, macOS, Windows, and iOS.
> The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them.
Care to cite this statement?
> As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
Yes, literally from you: "Passkeys should never be allowed to be exported in clear text." https://github.com/keepassxreboot/keepassxc/issues/10407 Also, "You absolutely should be preventing users from being able to copy a private key!"
> You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
But I want to use Apple Passwords. And I do use Apple Passwords for passwords.
What you're saying, in contrast, is that in order to use passkeys, I would be forced to change how I currently store credentials, which is not in iCloud. "You can choose any method you like, except the one you currently like" is a pernicious interpretation of "choice".
You're quoting the first post of a long discussion, where the importance of protecting your data on disk was highlighted, and a proposal was made that at minimum, the default should be encrypting the backup with a user selected secret or key.
> But I want to use Apple Passwords.
You're choosing to use an app that doesn't meet your needs, when there are numerous apps out there that do meet your needs. I'm not sure how anyone is supposed to solve that for you.
> At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key.
It feels like this stated minimum is not your actual minimum.
Consider for example a macOS user keychain. The keychain is encrypted on disk with a user-selected password. But once you unlock the keychain with the password, you can copy and paste passwords in clear text. The keychain is not a black hole where nothing ever escapes. And I have no objection to this setup; in fact it's my current setup.
So when you say copy and paste of passkeys in clear text is not a good idea, there's nothing inherent to encrypting credentials with a user key that prevents such copy and paste. There would have to be some additional restriction.
> This is currently being defined and is almost complete.
>> no signed stamp of approval from on high
> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.
Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
Unclear how this quoted comment relates to what I was replying to (which was about exporting / backing up your credentials).
But I'll respond.
> Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
If a website were to block your custom software's AAGUID for some reason, you can change your AAGUID.
AAGUIDs in the consumer passkey ecosystem are used to name your credential manager in account settings so you remember where you saved your passkey.
Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.
At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords.
> The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials.
I’ll accept that the attestation parts of the protocol may have had some ulterior motives (though I’m skeptical), but not having to reveal your credential to the verifying party is the entire benefit of passkeys and hugely important to stop phishing. I think it’s disingenuous to argue that this is somehow unnecessary.
> not having to reveal your credential to the verifying party is the entire benefit of passkeys
I think you misunderstood what I was talking about. The credential exchange protocol is for exporting passkeys from one credentials manager and importing them into another credentials manager. It has nothing to do with the relying party.
It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support.
For the general public, they already rely on either Google or Apple for pretty much all of their digital life. Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
> It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support.
I don't want to use a Yubikey. It's a pain in the butt. I just want to use my Mac, with no more damn dongles.
Keepass is a vendor, and one who doesn't even have a Safari extension.
> Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
I didn't say there was anything wrong with extending this to passkeys. The problem is the lock-in, e.g., Safari requires iCloud keychain for passkeys, but not for passwords. And there is no plaintext export/import, unlike with passwords.
Nobody can convince me that passkeys are good when I buy a Mac and use the built-in Safari but can't even use passkeys to log in to websites unless I give my passkeys to a cloud sync service or have to install some third-party "solution" (for a problem that should not exist in the first place). That experience is so much worse than passwords.
All of the 3rd party credential managers I’ve used that support passkeys work with safari, and through the APIs that Apple offers the credential managers you can even pick your default CM and never think about iCloud again…
Passkeys seem to be the best solution for users whose technical chops cannot be trusted, and who are also gullible enough to be a scam / social engineering target. Which, to my mind, describes a large enough chunk of audience of most popular services.
A tech-savvy relative of such a user should help them generate rescue codes, write them on a piece of paper, and store them along with all other important documents. Ideally the paper should also read: "Call me before using any of these codes! <phone number>."
A "user agent", I suppose. The agent could identify you to online services, and it does. Remembering and typing a passphrase is often too hard (or "too hard") for some users. A passkey is better than a password like 123456 or name + year of birth, or other such "easy to remember" passwords people invent to avoid remembering a passphrase. Especially if you have a hundred logins.
A passkey basically offloads user identification to the OS (especially a mobile OS). It should not be the only way to identify though.
An ssh-style key + password is fine. A username + password + TOTP should also be fine. But 99.9% of passwords should be in a password manager anyway.
Rescue codes should always be generated and written down when activating a passkey or similar, but this requires certain discipline, some feeling of importance. And many web sites that require registration don't seem important for users, especially one-time users. What makes sense for your Google account, or your bank account, feels like too much ceremony for a low-stakes login like a random online store; losing a login to it does not feel like a big loss to many people.
1) force the type of passkey stores used (e.g. hardware vs software) when I am providing the passkey store
2) force me to MFA (e.g. forcing touch ID, entering pin or unlock password, etc) when attempting to use a passkey
I'll continue to stick to plain old boring password + TOTP. I fully understand the security trade-offs like phishing resistance but password + TOTP is secure enough for me.
Many/all? also need to have some form of manual input as a backup, so you're not forced to sync all your passwords to e.g. a library's computer just to log in, if your house burns down or something.
(1) is already true today. There is no way for services to enforce whether a passkey is stored in software or hardware.
(2) I understand you don't like the user experience. But to make a technical clarification: requiring a user action to prove there's a human involved in the login action (e.g. by clicking a button in UI or requiring Touch ID) does not necessarily mean there's another factor involved at all (MFA). What you are describing is more of a "liveness check" than a separate factor/separate credential.
(1) is already true today. There is no way for services to enforce whether a passkey is stored in software or hardware.
Challenge: Go and try to register a non-blessed passkey type with PayPal and come back and share your experience.
(2) I understand you don't like the user experience
Pretty much my complaint. Passkeys allow for service providers to do dumb things that result in terrible UX. With Password + TOTP, I don't get asked to touch a sensor, enter a PIN, enter an unlock password, etc.
The "Vendors Can Lock You Out" part is what makes passkeys entirely a non-starter for me. Especially the additional risk when someone passes away and the heirs are trying to get access to the deceased's accounts. Vendors are well known for saying "we had an agreement with Samantha, and with her death, that agreement has terminated, and no one can be given access that was not pre-designated."
> "we had an agreement with Samantha, and with her death, that agreement has terminated, and no one can be given access that was not pre-designated."
It would be nice if you could use some legal apparatus to ratchet these agreements into a trust. Corps would hate it though, so it will probably be illegal to do.
It’s “illegal” in the sense that you could write whatever you want in your will but it wouldn’t be binding. You cannot force a party into a legal obligation they do not agree to.
The government can, though. I’m not sure if there’s any existing laws pertaining to transfer of or access to general accounts after death (as opposed to bank accounts which I’m pretty sure there are laws about).
My will says that my executor can access my accounts which alleviates Apple from legal risk if they do grant access but I’m pretty sure they are not obligated to do so.
This reminds me of some past political debates around same-sex marriage, where I encountered some folks claiming government-involvement wasn't really necessary because Free Contract could take care of everything. (This was some years back before the US Libertarian party imploded.)
It was rather frustrating to watch: "You're a huge fan of X but don't know how X works?"
For example, two people can't make a contract between them that gives one the right to visit the other in a hospital, nor the right to make medical-care/power-of-attorney decisions. You also can't contract-away the guardianship (or ownership) of children, etc.
I thought the Libertarian claim was that lawsuits would fix everything. Because after your house burns down and kills you due to no electrical codes being enforced, your family can sue the electrician (who might also be dead due to unrelated reasons) and convince a jury that they didn’t follow undefined best practices and be awarded millions of dollars that the electrician probably never had and certainly won’t pay and that’s better than having you alive anyway. Hooray for the free market.
Some password managers provide an offline root of trust which family members can use in this scenario. For example, 1Password tells users to print off an "Emergency Kit" which is a physical piece of paper with secret recovery codes printed on it, which they store in one or more safe places. [1]
If someone passes away, their family members can use the Emergency Kit to gain access to and use all their credentials - including their passkeys.
(The Emergency Kit also allows you to recover your data in the event that you forget your master passphrase or lose all your devices.)
There's nothing different about using a password vs. a passkey that makes it easier or harder for vendors to lock you out. I am not sure where this misconception comes from.
Whatever process a vendor requires someone to go through in order to gain access to someone's account when they pass away remains the same whether the user previously used a password or a passkey to login.
Are you aware of any vendor that actually does have differing policies based on the account's login credential type? I'm not aware of any.
The only one who can lock me out of my relationship with e.g. HN is HN.
With passkeys:
Now I can be locked out by HN or by the passkey provider.
Sure I could use a local passkey provider, but the protocol provides a way for the site to enforce a whitelist of passkey providers, so it's not clear that would be an option. Particularly for businesses like banks which tend to adopt an approach of "if a security restriction is possible, it should be applied". Or even just the typical tech PM perspective of "we want to include logos for the log in with X, and I think more than 5 logos is ugly so let's just whitelist Lastpass, 1password, Google, Microsoft and apple and be done with it"
If I want to move a password, I either already have it memorized or I find it in my manager and write it down.
If I want to move a passkey out of my Apple keychain, last I heard the answer is to just make a new passkey. The important part of the secret is 100% under their control. It makes me very squeamish
I hate passkeys because when I've encountered them it's always an interstitial between what I just signed in to and where I'm trying to go, it's always a "register a passkey now" with an obfuscated dark pattern bypass, and it's always on a corporate account that I don't need a fucking passkey for.
I don't want a passkey on my logins but there is no way to disable this prompt on the 3 websites that constantly annoy me for them.
Drives me batty. The company I work for is already paying you for the service I'm using. We use SSO for EVERYTHING, I've already 2FA Authenticated the login, and even if I set up a passkey I will still have to 2FA the login.
I don't use these sites in any personal capacity, and I would never use a site that harasses me in any way if I was not absolutely required to in order to earn a paycheck.
You're not going to get any money out of me, why are you torturing me?
Passkey just suck, end of story. The UX for them is so bad. I have no idea how many active pass keys I have. I just have to trust the provider knows what they're doing. Sometimes my authenticator app seems to forget my pass keys which is even more annoying.
TOTP is really annoying IMO but at least you control it so you can make it one-factor again if it's foisted on you. I made a Chrome extension to do that:
Password + TOTP have served me well so far. To port from device to device I just need to log into my Bitwarden account. It is unclear to me what device loss would do to a passkey and the passkey never communicates that information to me. If I set up a passkey on my iPhone, the site prompts me on my Linux desktop. I understand it's fine for people who use single platforms for everything. But as far as I can tell there is no advantage over Password + TOTP. I really hope Passkeys don't become mandatory. I only use them for sites I don't care about or when I've accidentally said yes to setting one up.
If you had multiple devices set up on the site (each site must have done this individually), you just use a different device.
If you had synced your passkeys somewhere (note that the spec allows sites to block this, though I'm not aware of any actually doing so), you sync them to the new thing and log in normally.
If you did none of those, it's gone forever. Do the account recovery process, if one exists.
So it degrades to equal or worse than passwords in all cases (which cannot block backups or syncing, and you can enter them individually by hand so you're not exposing all your passwords to the device, and you can communicate them over the phone or in writing), for device loss purposes.
Restoring access in this scenario is imo one of their worst qualities.
I have been working with computers since 82, on the Internet since 88, on the web since 92 and in the IT industry since 97.
I have yet to see any solid, significant evidence that passkeys are materially more secure than a random 32-character password + TOTP 2FA.
If a site or app refuses to let me create my own login and forces me to use a provider, I’m not going to be a customer under any circumstances.
If a site or app refuses to let me use a password+TOTP combination (as in, it forces passkeys), I am similarly out.
That’s not to say I don’t use passkeys. I have them on my Microsoft accounts, for one. But that is only after I have fully set up the account, and that the account plays very nice with the Microsoft Authenticator app, even going so far as to do challenge-response auth in coordination with the app, and plumping TOTP up to 8 characters.
Will I switch to passkeys elsewhere? Not for some time to come. My passwords make use of the entire two-byte UTF-8 character set, in that less than ½ of all characters typically generated can be found on a U.S. keyboard. So long as websites don’t restrict password length to moronically short values, a 32-character password with 2,048 possibilities for every character ought to be reasonably difficult to crack.
> I have yet to see any solid, significant evidence that passkeys are materially more secure than a random 32-character password + TOTP 2FA.
I think the main selling point of passkeys is their ability to prevent phishing.
A 32-character password + TOTP can still be entered on a phishing website, e.g. if you happen to follow a fabricated link. With passkeys, this is not possible by design.
> A 32-character password + TOTP can still be entered on a phishing website, e.g. if you happen to follow a fabricated link.
…How? The password manager only permits exact links. If the URL does not have the UTF-8-identical characters to the correct url - at which time, IT IS the correct URL - it will simply not populate the username and password fields.
Which should be made illegal on a national/international level.
The only possible reason for that is sheer laziness or malicious ignorance. Full stop, end of story
And I also include eMailed login links and eMailed 2FA in with that determination. Any secure login attribute that gets transmitted over eMail or SMS should be illegal. Password reset links, only. And vendor-locked/vendor-specific apps as the only 2FA path should also be illegal. TOTP should be a fully open system, letting anyone use any legitimate provider or app.
Yeah, let’s just say I have some pretty strong opinions.
I also think there's still an enormous ignorance from passkey devs that lots of people want to occasionally log into personal services from locked down corporate machines, and the flow to deal this is at best terrible but more often non-existent, and developers with typically enhanced privileges just aren't able to conceive how difficult this is.
Logging in to a personal service from your locked down corporate machine with a passkey works like this:
1. Start to login to the site.
2. When it gets to the point that you would choose to use a passkey if you were logging in at home, there should be some option that lets you say you want to use a passkey on another device. You can use that to tell it you want to use a passkey that is on your phone.
3. It gives you a QR code to scan with the phone, and then you complete the login using the passkey manager on the phone.
This is one of the core use cases for why FIDO Cross-Device Authentication was created. To be able to use a passkey to sign in on a shared device, a device you don't control, or a device where you just need temporary access to something.
On the one hand, that seems really important and I'm happy to know it exists.
On the other hand, I thought I had fully researched how passkeys work and literally never came across it.
So it kind of just continues to support my concern that passkeys are just too complicated to understand. If I'm at another device I need to log into, I would have just assumed I couldn't.
There needs to be a simple mental model for users. I'm not saying passkeys can't underlie that, but I think the UX still just hasn't been fully figured out yet.
I used the technical name for the capability, but you've likely run into it before.
If there is no passkey on the local device, a QR code will appear which you can scan with your phone or tablet, and use the passkey for the account from that device. It just kind of happens, typically without the user having to do anything special.
I will say though, corporate devices can be a bit of a wildcard as they are usually configured and locked down for a specific purpose. But the cross-device flow is generally not blocked by organizations.
I don't use passkeys, so I haven't run into it. It seems like that screen would be gated behind entering an e-mail address or username that is already registered with a passkey on another device.
What I'm saying is, I thought I had the right mental model of how passkeys work, after researching them, and that mental model told me you wouldn't be able to log in on a different device without going through a whole procedure to set up a new passkey, which you wouldn't want to do for something temporary.
The mental complexity is just too much for me to trust that if I adopt them, they'll work when I need them. The fact that I got this thing wrong means there's probably other things I'm still getting wrong.
I understand passwords and password managers and even 2FA. I feel like I can plan how to use them right so it all works and I don't need to worry about not being able to access my accounts. I just don't have that confidence with passkeys.
This is one of the core use cases for why FIDO Cross-Device Authentication was created. To be able to use a passkey to sign in on a shared device, a device you don't control, or a device where you just need temporary access to something.
Logged into Passkeys.io on my phone, and created a passkey.
Then tried to log in to it on my Windows desktop, using the "With my phone" option. First time around it failed to connect to my phone. Future times it connected, but told me that the phone had no appropriate passkeys on it. At which point I gave up.
Edit:
I then tried on GitHub, and it worked perfectly! Okay, that's pretty awesome.
If you’re not using bitwarden or equivalent they can’t be moved off a device you own at all, and even with it you’d need to download bitwarden which might be impossible
Passkeys are fantastic for the vast majority of the population. They solve oodles of problems. No more teaching ${FAMILY_MEMBER} about good passwords, password re-use, trying to explain how to use a password manager, etc. Instead: create passkey, done. Then it's seamless login whether they're on their computer, phone or tablet.
As a tech-savvy user fully aware of the underlying machinations involved with passkeys, I greatly prefer their simple, fast login experience over: username submit password submit TOTP submit, and especially over the much-worse "we've emailed you a code" login slog.
It's great until they break their phone, or spill coffee on it, or just lose it, and now they are locked out of EVERYTHING with no good way to get back in.
Passwords on a piece of paper for better or worse do not have that problem.
Only if they're not backing up their phone, which seems insane in this day and age.
And even if they're not, if they have a computer or tablet, the passkey will still be available there assuming they share an account.
You can also recover your iCloud Keychain via a designated/trusted Recovery Contact (e.g. spouse, who presumably hasn't destroyed their phone at the exact same time), or via iCloud Keychain escrow.
Both of the major smartphone companies (Google and Apple) have pretty robust account recovery processes. Are you familiar with all the options they have? Your comment gives me the impression that you are making assumptions about what would happen, instead of doing research on how it actually works.
I experienced Google's recently and it was very robust.
Even before passkeys, the average user would have major problems if Apple and Google didn't have good account recovery processes.
which is why at the very least your email provider gives you a recovery kit to print out (the equivalent of the notebook) and if you can get back into that account you'll likely be able to get into whatever else you signed up for.
There's no difference here between passkeys and any other central storage be it a password manager or a physical notebook. If you lose that access, well you're screwed. But it always beats having hotdog123 as your password for 70 different sites.
Android syncs them to your Google account and iPhone to your iCloud account by default. Which isn't a perfect solution but, again, is pretty good for most people.
And I just found out recently that you can't log into Google on a desktop without responding to a prompt on your Android phone. Which, if you broke said phone, you can't do.
There are a few alternate options like email or sms (I've used them several times, you have no option if you erase your only actively-used phone occasionally), but yeah. Google effectively forces 2FA whether you like it or not.
And that's great, as long as you're totally cool with access to _any_ of your accounts _anywhere_ being completely controlled by either Apple or Google.
Have you ever been locked out of your Apple account?
Maybe because your kid was playing with your phone and kept entering the wrong passcode and now you’re locked out for several hours?
Or because Apple detests anyone else touching your phone and you’re traveling internationally and your screen cracked and you took it to a local repair shop which in the process of replacing the screen triggered something Apple didn’t like and you’re locked out for a decade.
Your credential manager provides this sync and backup capability. There are dozens of credential managers available that work on all platforms. You don't have to use the default one on any given platform.
When was the last time you used a library computer, let alone logged onto a private service with it? This was a bad idea even 20 years ago. In today’s security climate, aw hell no.
Or my sisters laptop. & Fairly recently actually, to print something. Most accounts I don’t care that much about & two factor should be enough to save me I hope.
iCloud Keychain (or whatever the Google equivalent is). And as I said, it's a fantastic solution for the vast majority of the population (which, coincidentally, are also not Hacker News readers).
Huh? I’ve seen zero implementations that work seamlessly across computer, phone, tablet - unless they are all single platform, which I have yet to see anyone actually pull off.
It's a beautifully simple experience for Apple users across all their devices.
I can't speak for other platforms; I stopped helping ${EXTENDED_FAMILY} with non-Apple questions because the crap I had to diagnose, debug and deal with for Windows and Android was worse than ${DAY_JOB}.
Everyone pretends that you're force to only have 1 passkey. I use 3 "passkey managers": Passwords.app, Bitwarden, YubiKey hardware key. I usually add all 3 or just two (skipping YubiKey).
On Apple devices I get neat experience out of the box, on Linux (+Firefox) I forced to use Bitwarden because Mozilla is being Mozilla.
Yep. I use Apple’s direct support which works out of the box. I also create a second passkey in 1Password. And for truly important accounts (1Password itself, Apple, Google), I have a third copy on a YubiKey stored in a safe deposit box.
I dont want to use google/apple/microsoft for any credential manager because: google is evil; apple has locked me out of my apple id (and lost things like the recordings of conversations with my father during his hospice); microsoft keeps getting worse and more annoying to use.
So ok, I need some credential manager. I used keepass previously... but how do I vet other credential managers? I dont want an online backup. I want my credentials to only be on my computers. So now I gotta learn about which apps are ok, don't have cloud synching, can export files, and be compatible with MacOS.
And I have to learn what is FIDO? Like FICO? why do I need to synch with FIDO? what is it? will it give my credential store to others?
How is this easier or more convenient than a user/pass with 2fa?
I feel like I am going to accidentally leak my credentials and have no way of knowing
> I dont want an online backup. I want my credentials to only be on my computers. So now I gotta learn about which apps are ok, don't have cloud synching
If an "online" password manager uses end-to-end encryption, then the credentials really are only on your computers. The only thing "in the cloud" is encrypted blobs of data being moved around for the purpose of device sync and backup.
This insistence on using local non-syncing password managers is a masochistic exercise in making life difficult for yourself with no security benefit.
Let me rephrase: for the majority of users, the usability and resilience benefits of synced credentials are enormous, and the security costs are marginal at best. But this rests on a number of assumptions. YMMV.
In your case it's literally the same "complexity" as user/pass with 2FA. You need something to manage the passkeys, just like you need something to manage your second factor. Everything else you list as a worry is already in play.
FIDO is a standards body which produces specifications used by these systems.
One thing I genuinely hate about modern tech is that it punishes you for planning ahead. I purposely spent time getting a password manager and implementing 2fa protocols that would both speed up my time and keep me safe. Then suddenly every company decided it was time to go passwordless or do passkeys and all my work (researching different products, setting each one up, making sure hey work on all my devices, etc etc) suddenly goes down the drain
Passkeys need a marketing campaign and UX overhaul.
I’m a technical guy, but I really don’t understand what the fuck is going on when I use a passkey. All I know is one day it appeared as an option and it let me login to things. I don’t really understand where it lives, what device it’s tied to, how scanning a QR code on Google Chrome on my phone magically logs me in, etc etc.
The user was not educated on this. Hacker News is the top 1% of computer power users. You gotta understand to someone’s grandma or mom or brother who works in real estate none of this makes any sense nor will they educate themselves on what it is.
How do you use your passkeys? Do you have them sync with your apple or google accounts?
I've only experienced using passkeys with 1password and it's smooth as butter. Assuming 1p is unlocked,
To login: press login with passkey on website -> press sign in on 1p extension pop-up -> done
To create account: click create passkey on the website -> click save on 1p extension pop-up -> done
Tbh i think it's more important to get people to use password managers than passkeys.
Right now, when I go to the security section of my Amazon account in Chrome, it (unasked) prompts me to add a passkey, and the popup on my Mac says, verbatim:
> Add a passkey? "amazon.com" supports passkeys, a stronger alternative to passwords that cannot be leaked or stolen. A passkey for "xxxxx@xxxxx.com" will be saved in "Passwords". Touch ID to Save Passkey Cancel
I don't have the slightest idea what "Passwords" is as the destination. My iCloud keychain? My Google account? My 1Password?
OK, on the one hand TIL -- thank you! That's a super-meaningful piece of information.
On the other hand, you can understand why that is not remotely clear from the message. It's a generic term in quotes. If it said it would be saved "in the Passwords application (and synced to iCloud)", then I'd actually understand it.
So Apple is either being intentionally obtuse or incompetently confusing here, and I don't know which is worse. And it's UX crap like this which is why I still won't use passkeys, because I don't know where anything is going.
Exactly passkeys are confusing to the laymen (and not Laymen) because it’s is an orchestration across multiple services and devices.
If I’m using a passkey to login to my Gmail via chrome browser but used my phone what just happened - did it save in chrome? My Google account? My iPhone?
Totally agree with this. Passkeys are a solution but not the sole solution. There is absolutely a misconception for seeing them as newest and therefore the best choice.
It's not really passkeys that are the problem, it's trusting your passkey to a third-party. But this is still a minor part of the market today, a much bigger problem to warn people about is the "log in with your google/facebook/etc account". Where you're handing everything over to a third-party as well, because it's so easy and convenient.
Passkeys, stored in Bitwarden, give a lot of the same convenience, but without the vendor lock-in. We shouldn't be scaring people away from passkeys, when commonly used alternatives are much worse.
It's the fact that there's no physical artifact that's the problem - there's no file.
You can't back up your passkeys and wind up with something you put in a safe on a USB key or something and vendors have been aggressively trying to make that harder.
I update a spreadsheet with all my accounts and money and their values so I know my net worth and its changes, and oh boy every month getting these numbers is such a chore.
Since it's been a few days, sometimes I am logged out of either bank/traders and also the password manager.
So it's open the bank site, click on login/password, password manager browser extension asks to login. Type password manager password. It asks for 2FA. Unlock phone with face. Find app, open app, unlock app with face. Approve password manager login. Click on bank login/password again. I am in! No, bank wants to 2FA with mobile. Unlock phone with face. Open bank mobile app, unlock with face. Get code or approve login. Back to computer, type code or click approve.
Repeat that 12 times for all the accounts, and by the end of it I have neck pain with all the "pick up phone to face unlock" motions.
I am a bit paranoid so I turn on 2FA and passkeys and whatnot, but all of this makes me want to use `123password` everywhere and never change it.
For me everything goes in Keepass. And the only thing I want in life is the ability to change a password from Keepass in a standardized way.
Instead we've got Passkeys and the general promise by omission that I will be banned from using Keepass to store and backup my passwords as I see fit on my own devices.
People want me to trust the corporate overlords who at every turn have practiced lock in and rent seeking tactics.
Apple has offered an “iCloud for windows” app for ages that literally syncs your iCloud Keychain (passwords and passkeys) to a windows box where you can use browser extensions for chrome, edge, etc.
The biggest problem I have with passkeys is being tied to a single device you still need a flow to reset/get in _without_ the passkey. As you're only as secure as your weakest link passkeys don't add any security.
That said, if you have a mac with a fingerprint scanner they sure are very convenient option.
And don't get me started on terrible vendors like Rippling that only support a single passkey! Madness.
I dropped my phone and it literally fell apart. As a result I have been locked out of my AWS account. The get a phone call verification just does not work. Only saving grace is that it was an account I used to test things.
I keep hearing it repeated, but where does this "tied to a single device" idea come from?
The default, built-for-the-masses implementation of passkeys is called "synced passkeys". They are designed to sync between all your enrolled devices, ideally using end-to-end encryption.
You authenticate with whatever device you happen to be using at the time - phone, tablet, laptop, desktop - doesn't matter. If you lose one, you replace that device and re-enroll - then all your passkeys magically re-appear on the new device.
If you're cross-platform, modern password managers work across ecosystems - for example, 1Password syncs passkeys between Mac, Windows, iOS, Android, and Linux. If you're all-in on Apple, their native passkey implementation syncs passkeys between all your Apple devices. I thought Google and Microsoft do something similar now.
It's a real mystery why people believe passkeys have to be stored on your phone only.
There are many cross-platform password managers that sync very nicely, which would solve for the machines you control - the Windows gaming machine and Android phone.
For machines you don't control, such as your employer Mac, well that's a special case. In theory you can use "FIDO Cross-Device Authentication", which is a passkey flow designed specifically for authenticating on one device using a passkey stored on a different device, and involves scanning a QR code.
I've never tried this though. Personally I tend to avoid mixing personal stuff with work stuff, so the problem rarely arises.
Because by default, they do, and you have to explicitly install software to let it be moved. And even if you do, it’s discouraged and the spec is allowed to deny you access.
Not exactly. For example, the default credential manager on Android is Google Password Manager, which works on Windows, macOS, iOS, and Ubuntu. There are also dozens of other third party choices.
Last I heard, they were pushing hard for resident keys only, maybe that's changed. I don't like that there's still the option to restrict it to that in the same way having the option to force remote attestation makes me uneasy.
A passkey is a discoverable credential (aka resident key) in spec terminology. But the type of credential has no relationship to attestation (which is not used in the consumer passkey ecosystem).
Just to point out, protecting a key using the secure enclave and syncing it using end-to-end encryption aren’t necessarily mutually exclusive.
The security property you care about is that the plaintext key is only ever processed in use within the secure enclave (transiently, during authentication).
That doesn’t preclude syncing or backing up the encrypted key via a cloud service - if the device allows the application to do that.
Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.
How do the decryption keys for the encrypted passkeys get shared between devices?
>Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.
I wasn't referring to hardware keys (like YubiKeys), but rather on-device secure enclaves, TEEs, or TPMs.
Also I said "protecting a key using the secure enclave", which is perhaps a bit of a sleight of hand :-)
By that I mean a key that is wrapped (encrypted) using a parent key stored in the secure enclave. The key itself is not stored in the SE. But since it is wrapped using a parent key that is stored in the SE, that means it can only be decrypted in the SE. I believe this is how iCloud Keychain works, for example.
Digging into this further, it looks like I might have been wrong to imply that a credential manager app can instruct the SE itself to perform the proof of possession calculations needed for passkey authentication using a private key that is "protected" in this sense. When the app asks the SE to decrypt a passkey private key, it looks like the SE might return the passkey private key in plaintext to the app, and then the app itself performs the proof of possession calculation transiently outside the SE. I'm not sure about that, but I'd love to know.
> How do the decryption keys for the encrypted passkeys get shared between devices?
They get established as part of the device enrolment process. I suspect this simply adds another layer to the key hierarchy, so that your passkey private keys are encrypted under a sync key (parent) which is encrypted under a SE key (grandparent).
In that case, you could still claim that your passkeys are "protected by the SE" since they are encrypted at rest and in transit, and they cannot be decrypted anywhere except in the SEs of your enrolled devices.
> Because by default, they do, and you have to explicitly install software to let it be moved
Apple's native passkey implementation doesn't require doesn't require you to install extra software, and the passkeys sync by default. I thought Google's and Microsoft's were similar - but I haven't tried them.
> And even if you do, it’s discouraged
Really? Where is it discouraged? I thought synced passkeys are intended as the solution for consumers.
> the spec is allowed to deny you access
Yeah but I thought that's for enterprise use cases, not consumer. E.g. employers that want to enforce device type restrictions on their employees.
It does if you want to share accounts between my iOS phone and Linux desktop. And it still puts you entirely at the whims of Apple, etc. if you’re allowed to log in to unrelated accounts.
& I think it is mostly being used for enterprises for now ,but much like TPM and remote attestation running on “my” computer, I don’t like that it’s an option
I don't care what you other people in auth do, I work in auth too, please stop making signing into anything 5 steps.
1. First I get redirected to a special sign-in page.
2. Then I sign-in with my email only.
3. Then it finally asks me for a password, even for services that would never reasonably use SSO or have another post-email receive process.
4. Then I get redirected again to enter 2fa.
5. Then these websites ask if I want to create a passkey. No, I never want to create a passkey, and you keep asking me anyway.
6. Then, and only then, do I get to finally go back to using the service I wanted, and by then, you've lost whatever my `?originalUrl=` was, and I have to find it again.
No, don't send me a magic link. Because then I have to go do 4 more steps with Gmail or another mailbox provider and now signing in has become 10 or more steps.
No, don't tell me getting rid of passwords will help most of the population, and then force all of us to do the above, and blatantly lie to us that it's better.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
I think part of the distress experienced by readers is due to mixing the fixed-width font with "text-align: justify". So it's close but not exactly fixed/consistent.
The author still has one last misconception about passkeys, namely that if you lose a passkey, you have "no recourse."
People wrongly think passkeys are like Bitcoin wallets, where losing them means there's absolutely nothing you can do, your account is simply lost forever.
Losing a passkey is exactly like losing your password, which is to say, that for 99% of services, you can reset your password/passkey really easily. There's a prominent "Reset Password" button right on the login form. It sends you an email or an SMS, you click it, and it lets you reset right then and there. You can reset your passkey in exactly the same way.
It is not that easy to reset if you lose your password to your Apple, Google, Facebook, etc. They all have a bunch of factors that they use to authenticate you if you reset your password, and they don't even document which ones they use.
So, if you care about those accounts, you've got to make sure you have backup access. They all let you generate and print "backup codes" (emergency passwords) and store them in a fireproof safe or a literal bank vault. Do that!
As everybody knows, you can't store all of your passwords in a password manager. You need something outside of the password manager to login to the manager itself. That's why 1Password/LastPass is called that; you still need one last password that you keep and manage yourself.
That's true of passkeys, too. You can login to Google with passkey, but if Google is your password manager that stores your passkey, you need something else outside of Google's password manager to login to Google. Whether it's a password, a backup code, a YubiKey, whatever, you need one more thing to login to Google, ideally more than one, so you can back it up and keep it safe.
Pre-passkeys, was this lockout issue a true issue with apple and google accounts? Or have passkeys added a general lockout issue that didn't exist before? Also passkeys in their current implementation are not possible to back up or export yourself, unlike passwords in the past.
Security engineers are prioritizing preventing key copying over lockout issues, unilaterally, on literally billions of people. It improves their metrics internally, at the cost of an externality on the entire world. This kind of stuff invites odious regulation as more and more stories of lockout with no recourse surface.
And unlike passwords, there is no good provider migration story. There is a roach motel issue. Yes it is being 'worked on', but passkeys and such have been out for many years, the willful denial whenever you ask people running these standards about these issues is incredibly irritating. The fact they tend to avoid questions about this like politicians decreases trust in the motives of such standards.
> unlike passwords, there is no good provider migration story
I'm curious what the "good provider migration story" you're referring to here for passwords is?
Password managers by-and-large haven't agreed on a standardised interchange format for import/export - a few of them have some compatibility helpers for importing from specific popular competitors but they're all in different formats, no consistent formats.
The above goes for passkeys as it does passwords - import/export will include your passkeys - so I don't see much difference in the provider migration story.
On the other hand, the FIDO Credential Exchange Format does solve the above problem (if/when providers choose to adopt it), so passkeys are at least further along the path of creating a "good provider migration story" than passwords ever were.
Copy & Paste one at a time is at least possible with passwords
And what about password sharing? I want to share everything with my partner,in case something happens to me.
Passwords right now are outright better.
And by the way, door keys could be copied.
I agree. I use passwords with TOTP whenever possible. Passwords in a locally stored database (such as KeePassXC) can be easily shared. TOTP using Google Authenticator can also be easily shared, not just with my partner, but also among my own devices. Right now I see this as a much better, simpler, and much easier to understand option. BTW, the "easier to understand" is a big feature. Passkeys seem to be complex; just look at all the arguments about them in these comments. And where there is complexity there is vulnerability.
1Password family plan, and I assume similar cloud password managers, let you organize passwords/TOTP/Passkeys into vaults, and you can put credentials you want to share with other family members here.
You can store passkeys in a password manager where they're either in a full-time shared config or there's some configuration that allows access if something happens. (e.g. Emergency Kit for 1Password, legacy contact for Apple account, etc.)
Add your partner's passkeys to your accounts, then you can both login. Or put some Yubikeys in a safe that can be accessed if needed.
> Pre-passkeys, was this lockout issue a true issue with apple and google accounts?
Yes, absolutely. I have a second Google account I created and lost the password to. I can't reset it because it wants to know the exact month I opened it. I don't even know if it was 2012 or 2016, I'll never guess the month.
Yes. People have complained about the difficulty of Google or Facebook account recovery and how they need to make it easier and more accurate for ages. You could search hn for "password reset" or "lost password" and you'll find tons.
> passkeys in their current implementation are not possible to back up or export yourself
You can with KeePassXC, so it is a choice of the credential manager implementation. The standards people want to ban such credential managers though.
The primary credential a user relies on for logging in (whether it's a password or a passkey) is pretty unrelated to the the "lockout issue". The lockout issue is really the age old question of: what happens if I can't do a normal email-based account recovery flow (aka "I forgot/lost my password/passkey").
The answer to that is stuff like this:
https://blog.google/technology/safety-security/recovery-cont...
https://support.apple.com/en-us/102641
No, passkeys haven't added a new general lockout issue, because Apple, Google, etc. don't allow you to create an account where you can only login via passkey with no external authentication factor. They require you have something outside the Google account, whether that's a password, a hardware key, etc.
People keep falsely imagining that Google is setting people up with passkey-only accounts, with no way to backup their login credentials. Gosh, wouldn't that be terrible?
That would be like 1Password letting you create a passkey-only account with no password, storing the only passkey in 1Password. The whole idea makes no sense. 1Password doesn't do that, and neither does Apple, Google, Microsoft, etc. (We can all imagine them doing something that stupid, but, it turns out, they don't.)
Pre-passkeys, the most common lost-credential scenario was creating a fresh Gmail address on a new device (an Android phone) with a password and forgetting both your Google password and your password for your cellular-phone carrier (AT&T, T-Mobile, etc). Your Google password would be stored locally on your phone and in Google's cloud, but when you lose your phone and forget your passwords, no backups remain.
At that point, you're pretty much screwed. Google can't email you a reset-password link, because Gmail is your email. Google can't send you a 2FA SMS until you get a new phone with the same number, but you can't convince AT&T to do that, because they want to send a reset-password link to your email, which you don't have, or SMS to your phone, which you don't have.
(The cellular carriers don't even allow you to show government ID at a physical store. They don't allow you to take over a phone number that way, because people could then threaten/bribe a T-Mobile store representative to falsely claim that you presented valid government ID, taking over other people's accounts. If you walk into a store, they'll just put you on the phone with customer service, where they'll insist that you provide your AT&T password, or reset your password via email or SMS. If you've lost your email and your phone and all your passwords, you're completely out of luck.)
If Google allowed you to create a passkey-only account, with no SMS 2FA and no way to backup your passkey, that would be even worse.
But, luckily for all of us, they don't even allow that, and they're certainly not pushing it unilaterally on billions of people.
I use passkeys. I save them in the Apple cloud. They work on all my apple devices seamlessly. I don't need to copy them. Ecosystems are nice.
And what happens when Apple permabans your account for buying a gift card? https://news.ycombinator.com/item?id=46297336
Thumbs up!
I use passwords. I save them in iCloud. Or Bitwarden. Or Chrome/Firefox. Or Lastpass. Or 1password.
They work on all my (not just Apple) devices seamlessly.
I don’t need to copy them.
Non walled ecosystems are nice.
Good for you, glad you like it.
This is not a feature of passkeys, this is a feature of each and every individual provider building their own unique reset flow.
Not every provider does this correctly. Just yesterday I saw someone complaining on mastodon about their passkeys being locked and requiring a phone call to get reset.
Passkeys are exactly as resettable as passwords, which depends on your provider actually implementing things correctly.
tbh I think it's safe to claim they're strictly inferior to passwords, though in almost all cases they're literally identical (as you point out).
e.g. that phone call case: some places will tell you a temporary password (over the phone) to enter next time, and then you come up with a new one when you log in. there is no equivalent flow for passkeys, because you can't enter them by hand. a site could of course build that for passkeys (like a temporary password with special UI for entering it), but literally every site with passwords can do that by default, it just needs a general admin UI which almost always exists.
(most I've encountered will email you a temp password, and in principle you could email a temp passkey too... but that doesn't work by phone / for manual entry, and is there a spec on that file format? I don't think so? in your password manager right now: is there a place to manually import a passkey for a website? half of mine don't have one for passkeys, but every single one I've ever seen has a way to manually enter a password)
> but literally every site with passwords can do that by default, it just needs a general admin UI which almost always exists.
Most sites/systems that are designed for security won't have such an admin UI - passwords should generally not be handled in a way where anybody other than the user is ever able to know what they are.
"I can erase a securely hashed password and set a new one" is very common and generally seen as safe, and does not at all require being able to "know what [the current password is]".
Most can do this. As a concrete example, phpMyAdmin has UI specifically for editing password fields: https://www.wpbeginner.com/beginners-guide/how-to-reset-a-wo...
Apple and Google often store your other 99% of passwords and passkeys, so losing this is actually more important than losing the 99%. I take your point but saying 99% have reset services when the critical 1% may never be recoverable without posting to HN is an important point.
For those you add recovery e-mails. You can easily have a Google, Microsoft and Yahoo e-mail so having access to at least one means you can recover the rest. Yes, this increases your attack surface, but the chances remain miniscule.
Just as a note: for E2EE services that use your password to decrypt your key to decrypt your data, a recovery email often recovers your user account BUT not your data (so you may get access to a blank account). It is perfectly possible to lose access to your data, that may include the rest of your passwords, if you have not set up other recovery methods which can actually decrypt your encryption keys, and rely on a recovery email or phone.
Also, just so I'm clear, there's no requirement to share passkeys. Or even have passkeys enabled on all devices, right?
If I log in to a site from my machine, and set up a passkey, but then log into that site from another machine, it'll just see no passkey present and ask for my password, yes?
A passkey is a local password on a device that could be shared through all the password manager gymnastics, but its not required as I understand it.
That’s true for all accounts that i’ve been using (Google, Apple, Microsoft).
Passkey generated on a device can only change login flow for this one specific device. If you don’t synchronize passkey to other devices or if you do not generate passkey on other device, then login flow is different for other device. You need to enter password.
Imo it would not make any sense if it was different.
I think there are passkeys that can be migrated/synced between devices, and device-bound passkeys that can't. I do save passkeys on my password manager and use them across devices, but I am pretty sure I have had passkeys that I could only use from a specific device. Not sure though, it feels a bit confusing.
Yes, that's right. It might also make sense to generate multiple passkeys for an account. For example, a separate one for logging in from Apple devices.
some sites actually let you use a passkey on another device to login. AWS is one.
in that case, passkeys are pretty useless considering that they can be bypassed by the other factors they were designed to eliminate in the first place.
Sure I'm super secure using a passkey.... except that there's always a "try another way" option on the login screen. Which defeats the purpose.
Vendor lock-in a serious concern. Just reading through this KeePass issue again and seeing how much pressure the industry is trying to exert to prevent the users from being able to export their own private keys should be concerning. I come back to this discussion every time I see someone arguing in favor of passkey adoption.
>The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers
https://github.com/keepassxreboot/keepassxc/issues/10407
Hi! I'm the commenter on that post that keeps being brought up!
I don't think requiring an encrypted backup (with a key or secret that YOU control) by default is "preventing users from being able to export their own private keys".
Hi! I have no issue with having the backup being encrypted by default, except the discussion returns again and again to disallowing any cleartext export, even when specifically requested by the end user.
And on a separate note, I fundamentally disagree for political reasons with the idea that the websites should be able to block specific passkey providers.
You say "requiring by default". That makes no sense in this context (or most) - you can either require something (which is not "by default") or you do not (at which point you can encourage something as strongly as you like, but it's still not required).
The github issue is quite clear about "requiring", not "by default", which is a restriction on what someone does with their own data. Particularly since AFAICT there is still no spec for data exchange over flat files. CXP is a probably-reasonable more-safe option to encourage, but it really shouldn't be the only option.
(arguably CXF only defines non-encrypted files, since it doesn't even recommend encryption options or provide a way to communicate what was used, except to say that it "MUST" encrypt or coordinate over CXP)
2 things about passkeys I wish would be fixed.
1. Passkey prompts asking if I want to use a phone or security key when I only have one (or neither!) registered. The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered.
2. Passkeys should have had the portability and flexibility that ssh keys have from the start. Making it so your grandparents can use public key cryptography and gain a significant advantage in securing their accounts in a user friendly manner should have been the priority. Seems like vendor lock-in was the goal from the start.
>The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered.
I disagree. It is very annoying when some service fails to show an option on the grounds that I can't use it. It makes it difficult to resolve problems. If the option is just missing, I have no way to tell whether the company doesn't provide the option, whether the company made some sort of mistake (they can't provide an email option because they lost my email), whether I made a mistake, or whether the company just has a bad UI that tries to hide the option. And don't forget the situation where I tried to google online for some help in using the UI, I found a 6 month old Reddit post showing the option, and I can't figure out if the company changed the UI in the past six months.
They should show it greyed out with a note "no key of this type registered".
That’s fair. I just meant that during logon, it is annoying to have to click through an additional prompt that doesn’t apply. But I can see where if there was an issue showing what all the options could be and if they are enabled or unavailable or you want to set it up, would be more beneficial than not.
On Mac with the security key you can just press the button on the security key before choosing a path. It only looks like a required extra step but in practice it is optional.
> Seems like vendor lock-in was the goal from the start.
Exactly. The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them. The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials. You can go from one passkey vendor to another, but you're always locked in to one passkey vendor or another.
Any credential system that makes it impossible to write something down on a piece of paper, take it to a new computer, and login to a website is just a gateway to vendor lock-in. You can manually manage your own ssh keys but for some reason not your passkeys.
As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. [EDIT: Obviously I'm talking about built-in support. I'm well aware of third-party software, so everyone can stop replying to this now, please!] You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
The passkey vendors took some good theoretical ideas, such as site-specific credentials and public-key cryptography, and totally mangled the implementation, making it hostile to everyone except themselves.
> passkeys in Safari requires iCloud Keychain
This is not true - browsers including Safari support passkeys managed by third-party password managers.
I'm using 1Password with browser extensions for Safari and Chrome on macOS and iOS and it works seamlessly with my passkeys, which are not stored in iCloud Keychain.
> you're always locked in to one passkey vendor or another.
This will change: https://1password.com/blog/fido-alliance-import-export-passk...
> This is not true - Safari also supports passkeys managed by third-party password managers.
I think you know what I meant and are just being pedantic here for no good reason.
Do you think I'm unaware of 1Password? I don't want to use 1Password any more than I want to use iCloud Keychain.
Technically, pendantically, Safari "supports" anything that third-party Safari extensions support. I'm a Safari extension developer myself. But this is totally different from how Safari supports the use of passwords, which is all built in, requires no third-party software, can be local-only, allows plaintext export/import, etc.
> This will change: https://1password.com/blog/fido-alliance-import-export-passk...
This is literally what I meant by the so-called "secure credential exchange" in my previous comment.
Reading the cfx spec [1], the raw private key is exported as a base64 encoded der. I don't understand what your concern is here. It appears that any cfx export file is not tied to a specific service to service import path, but can be imported into anything, or just used locally with self written tools.
1. https://fidoalliance.org/specs/cx/cxf-v1.0-ps-20250814.html#...
This is merely the exchange format between credential providers, which is encrypted and gatekeeped by the credential providers. None of this is exported to users.
OK I see what you mean. Having the ability to switch between vendors but not the ability to export your data locally (e.g. as plaintext keys) is a new meaning of "vendor lock-in" I hadn't considered before.
Yes. User freedom is not all-or-nothing. There are degrees, and the tech companies are coming up with fiendish new ways to lock away your data from you. So in the case of passkeys, you can technically move your data between vendors, though that can be quite inconvenient as the submitted article mentions, but nonetheless every vendor locks away your data from you, and most vendors have a financial incentive to keep your data away from you, so that you have to pay for the services.
Once "secure credential exchange" becomes supported by commercial credential managers, what's to stop someone implementing an open source password manager that implements the standard and allows local export in plaintext?
Passkeys relying parties can block providers. Tim Cappalli threatened the KeypassXC developers so.[1] The restrictions demanded now do not restrict user freedom significantly arguably. But the incentives and capabilities are clear.
[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
OK but you'd still be able to use the open source "password manager" to export the keys - which solves the issue lapcat raised in this thread - even if relying parties blocked it for authentication, which would be a separate issue.
Someone could develop a "passkey export tool" purely for the purpose of doing credential exchange then local export.
Or are you saying the credential exchange process itself could block providers?
You misunderstood lapcat I think. They wanted Passkeys stored locally exclusively. And they wanted to be able to use them. The issues are not separate.
Hi, Tim Cappalli here.
Not sure how stating that my (an individual) opinions on a topic are evolving is interpreted as "threatened the KeypassXC developers".
If you've been following along, you'll have seen that I am actually one of the biggest advocates of the open passkey ecosystem, and have been working really hard to make sure all credential managers have a level playing field.
Always happy to chat directly if you have concerns!
The threat you relayed was more serious than the threat you made. But it is a threat when a person with influence suggests they may support a punishment.
The biggest advocates of an open ecosystem say attestation should be removed and no one should adopt Passkeys before. Is this your position now?
The concerns were clear I thought. I would be happy to discuss this publicly.
Attestation is not used in the consumer passkey ecosystem.
But it could be. Yes?
Not really. The attestation model defined for workforce (enterprise) credential managers/authenticators doesn't really work in practice for consumer credential managers.
> doesn't really work in practice
Avoid weasel words please. Is it possible in theory to use attestation or any other Passkeys feature ever to prevent a user to use any software they chose with any service they chose?
In theory any code could be written at any time that does something good or bad. Sure.
But in reality, the people who actually work on these standards within the FIDO alliance do not want a world where every website/service makes arbitrary decisions on which password managers are allowed. That would be a nightmare.
Will be a nightmare. If they really didn't want this they wouldn't have put the tool to do it right in the spec.
This is obviously kicking the can down the road, but I "solve" this problem by storing passkeys in a third-party credential manager that supports them. That way I can use them on any device that I've installed the client app or browser extension on. I have this working on Fedora, macOS, Windows, and iOS.
But again, kicking the can down the road.
Well, you can until they use the attestation feature to block your passkey manager implementation.
> The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them.
Care to cite this statement?
> As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
> Care to cite this statement?
Yes, literally from you: "Passkeys should never be allowed to be exported in clear text." https://github.com/keepassxreboot/keepassxc/issues/10407 Also, "You absolutely should be preventing users from being able to copy a private key!"
> You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
But I want to use Apple Passwords. And I do use Apple Passwords for passwords.
What you're saying, in contrast, is that in order to use passkeys, I would be forced to change how I currently store credentials, which is not in iCloud. "You can choose any method you like, except the one you currently like" is a pernicious interpretation of "choice".
You're quoting the first post of a long discussion, where the importance of protecting your data on disk was highlighted, and a proposal was made that at minimum, the default should be encrypting the backup with a user selected secret or key.
> But I want to use Apple Passwords.
You're choosing to use an app that doesn't meet your needs, when there are numerous apps out there that do meet your needs. I'm not sure how anyone is supposed to solve that for you.
> You're quoting the first post of a long discussion
"You absolutely should be preventing users from being able to copy a private key!" is the 8th post in the discussion.
Do you stand by these words, or are you now repudiating them?
> You're choosing to use an app that doesn't meet your needs
I am using an app that meets my needs. I don't need passkeys. It's just other people telling me that I need passkeys.
Copy and paste in clear text? Yes, I don't think that's a good idea. Download to disk in clear text? Yes, I don't think that's a good idea.
Years and years of security incidents with consumer data show that this is a really bad idea.
At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key.
> At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key.
It feels like this stated minimum is not your actual minimum.
Consider for example a macOS user keychain. The keychain is encrypted on disk with a user-selected password. But once you unlock the keychain with the password, you can copy and paste passwords in clear text. The keychain is not a black hole where nothing ever escapes. And I have no objection to this setup; in fact it's my current setup.
So when you say copy and paste of passkeys in clear text is not a good idea, there's nothing inherent to encrypting credentials with a user key that prevents such copy and paste. There would have to be some additional restriction.
> At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key.
What should happen if the developers refuse to enforce this?
Quoting your comments on github [0]
>> There is no passkey certification process
> This is currently being defined and is almost complete.
>> no signed stamp of approval from on high
> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.
Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
[0] https://github.com/keepassxreboot/keepassxc/issues/10406#iss...
Unclear how this quoted comment relates to what I was replying to (which was about exporting / backing up your credentials).
But I'll respond.
> Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
If a website were to block your custom software's AAGUID for some reason, you can change your AAGUID.
AAGUIDs in the consumer passkey ecosystem are used to name your credential manager in account settings so you remember where you saved your passkey.
Well it relates to this sentence:
> You can use any credential manager you choose.
Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.
At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords.
If a website were to attempt to do this, you (or your credential manager) could simply change the AAGUID to match another credential manager.
> what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain
Completely untrue, Safari on both Mac and iOS supports third-party password managers for both traditional passwords and passkeys.
You're repeating yourself and also way too many pedantic comments here: https://news.ycombinator.com/item?id=46304159
> The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials.
I’ll accept that the attestation parts of the protocol may have had some ulterior motives (though I’m skeptical), but not having to reveal your credential to the verifying party is the entire benefit of passkeys and hugely important to stop phishing. I think it’s disingenuous to argue that this is somehow unnecessary.
> not having to reveal your credential to the verifying party is the entire benefit of passkeys
I think you misunderstood what I was talking about. The credential exchange protocol is for exporting passkeys from one credentials manager and importing them into another credentials manager. It has nothing to do with the relying party.
Oh, indeed, sorry. Yes I thought you were talking about the authentication process.
It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support.
For the general public, they already rely on either Google or Apple for pretty much all of their digital life. Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
> It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support.
I don't want to use a Yubikey. It's a pain in the butt. I just want to use my Mac, with no more damn dongles.
Keepass is a vendor, and one who doesn't even have a Safari extension.
> Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
I didn't say there was anything wrong with extending this to passkeys. The problem is the lock-in, e.g., Safari requires iCloud keychain for passkeys, but not for passwords. And there is no plaintext export/import, unlike with passwords.
Nobody can convince me that passkeys are good when I buy a Mac and use the built-in Safari but can't even use passkeys to log in to websites unless I give my passkeys to a cloud sync service or have to install some third-party "solution" (for a problem that should not exist in the first place). That experience is so much worse than passwords.
So don't use software that forces lock-in (Safari)? Sounds like a you problem.
> So don't use software that forces lock-in (Safari)? Sounds like a you problem.
No, this is a passkeys problem. Safari does not force lock-in of passwords.
Why in the world would I want to ditch my web browser just to use passkeys? I'd rather ditch passkeys.
Again, this is a Safari problem, not a passkeys problem. You are literally complaining about missing features in Safari.
> Safari requires iCloud keychain for passkeys
Repeating this doesn’t make it true. https://developer.apple.com/documentation/authenticationserv...
All of the 3rd party credential managers I’ve used that support passkeys work with safari, and through the APIs that Apple offers the credential managers you can even pick your default CM and never think about iCloud again…
> All of the 3rd party credential managers I’ve used that support passkeys work with safari
I've already addressed this pedantry: https://news.ycombinator.com/item?id=46304137
Rather ironic to complain about lock in as an Apple user, there is no such problem on Linux. The problem isn't passkeys but Apple.
[dead]
Passkeys seem to be the best solution for users whose technical chops cannot be trusted, and who are also gullible enough to be a scam / social engineering target. Which, to my mind, describes a large enough chunk of audience of most popular services.
A tech-savvy relative of such a user should help them generate rescue codes, write them on a piece of paper, and store them along with all other important documents. Ideally the paper should also read: "Call me before using any of these codes! <phone number>."
it's just a further step whittling away of browsers being a "user client".
a key based approach is great. Knowing (the passphrase) and Having (the key) is a good way to authenticate.
A "user agent", I suppose. The agent could identify you to online services, and it does. Remembering and typing a passphrase is often too hard (or "too hard") for some users. A passkey is better than a password like 123456 or name + year of birth, or other such "easy to remember" passwords people invent to avoid remembering a passphrase. Especially if you have a hundred logins.
A passkey basically offloads user identification to the OS (especially a mobile OS). It should not be the only way to identify though.
An ssh-style key + password is fine. A username + password + TOTP should also be fine. But 99.9% of passwords should be in a password manager anyway.
Rescue codes should always be generated and written down when activating a passkey or similar, but this requires certain discipline, some feeling of importance. And many web sites that require registration don't seem important for users, especially one-time users. What makes sense for your Google account, or your bank account, feels like too much ceremony for a low-stakes login like a random online store; losing a login to it does not feel like a big loss to many people.
I'm a bit of a curmudgeon about this.
Until service providers are no longer allowed to:
I'll continue to stick to plain old boring password + TOTP. I fully understand the security trade-offs like phishing resistance but password + TOTP is secure enough for me.Many/all? also need to have some form of manual input as a backup, so you're not forced to sync all your passwords to e.g. a library's computer just to log in, if your house burns down or something.
Which probably looks a lot like a password.
(1) is already true today. There is no way for services to enforce whether a passkey is stored in software or hardware.
(2) I understand you don't like the user experience. But to make a technical clarification: requiring a user action to prove there's a human involved in the login action (e.g. by clicking a button in UI or requiring Touch ID) does not necessarily mean there's another factor involved at all (MFA). What you are describing is more of a "liveness check" than a separate factor/separate credential.
I actually kinda like the enter-a-pin flow, it makes me feel a lot safer about letting someone hold my phone. I just hate the lock-in it adds
Liveness check is fine, but I’ve always seen it as requiring Microsoft Hello or equivalent explicitly, and not whatever check I would prefer to use
The "Vendors Can Lock You Out" part is what makes passkeys entirely a non-starter for me. Especially the additional risk when someone passes away and the heirs are trying to get access to the deceased's accounts. Vendors are well known for saying "we had an agreement with Samantha, and with her death, that agreement has terminated, and no one can be given access that was not pre-designated."
That linked story is pretty horrifying too: https://hey.paris/posts/appleid/
If he can't get his account back in any reasonable amount of time what chance do I have?
(I see I missed a big HN discussion on this: https://news.ycombinator.com/item?id=46252114 - 1038 comments)
> "we had an agreement with Samantha, and with her death, that agreement has terminated, and no one can be given access that was not pre-designated."
It would be nice if you could use some legal apparatus to ratchet these agreements into a trust. Corps would hate it though, so it will probably be illegal to do.
It’s “illegal” in the sense that you could write whatever you want in your will but it wouldn’t be binding. You cannot force a party into a legal obligation they do not agree to.
The government can, though. I’m not sure if there’s any existing laws pertaining to transfer of or access to general accounts after death (as opposed to bank accounts which I’m pretty sure there are laws about).
My will says that my executor can access my accounts which alleviates Apple from legal risk if they do grant access but I’m pretty sure they are not obligated to do so.
This reminds me of some past political debates around same-sex marriage, where I encountered some folks claiming government-involvement wasn't really necessary because Free Contract could take care of everything. (This was some years back before the US Libertarian party imploded.)
It was rather frustrating to watch: "You're a huge fan of X but don't know how X works?"
For example, two people can't make a contract between them that gives one the right to visit the other in a hospital, nor the right to make medical-care/power-of-attorney decisions. You also can't contract-away the guardianship (or ownership) of children, etc.
I thought the Libertarian claim was that lawsuits would fix everything. Because after your house burns down and kills you due to no electrical codes being enforced, your family can sue the electrician (who might also be dead due to unrelated reasons) and convince a jury that they didn’t follow undefined best practices and be awarded millions of dollars that the electrician probably never had and certainly won’t pay and that’s better than having you alive anyway. Hooray for the free market.
In the United Stages, RUFADAA provides this legal framework and I think it's quite reasonable.
I wrote about it here: https://digitalseams.com/blog/what-happens-to-your-online-ac...
Some password managers provide an offline root of trust which family members can use in this scenario. For example, 1Password tells users to print off an "Emergency Kit" which is a physical piece of paper with secret recovery codes printed on it, which they store in one or more safe places. [1]
If someone passes away, their family members can use the Emergency Kit to gain access to and use all their credentials - including their passkeys.
(The Emergency Kit also allows you to recover your data in the event that you forget your master passphrase or lose all your devices.)
[1] https://support.1password.com/emergency-kit/
There's nothing different about using a password vs. a passkey that makes it easier or harder for vendors to lock you out. I am not sure where this misconception comes from.
Whatever process a vendor requires someone to go through in order to gain access to someone's account when they pass away remains the same whether the user previously used a password or a passkey to login.
Are you aware of any vendor that actually does have differing policies based on the account's login credential type? I'm not aware of any.
Without passkeys:
The only one who can lock me out of my relationship with e.g. HN is HN.
With passkeys:
Now I can be locked out by HN or by the passkey provider.
Sure I could use a local passkey provider, but the protocol provides a way for the site to enforce a whitelist of passkey providers, so it's not clear that would be an option. Particularly for businesses like banks which tend to adopt an approach of "if a security restriction is possible, it should be applied". Or even just the typical tech PM perspective of "we want to include logos for the log in with X, and I think more than 5 logos is ugly so let's just whitelist Lastpass, 1password, Google, Microsoft and apple and be done with it"
If I want to move a password, I either already have it memorized or I find it in my manager and write it down.
If I want to move a passkey out of my Apple keychain, last I heard the answer is to just make a new passkey. The important part of the secret is 100% under their control. It makes me very squeamish
I hate passkeys because when I've encountered them it's always an interstitial between what I just signed in to and where I'm trying to go, it's always a "register a passkey now" with an obfuscated dark pattern bypass, and it's always on a corporate account that I don't need a fucking passkey for.
I don't want a passkey on my logins but there is no way to disable this prompt on the 3 websites that constantly annoy me for them.
Drives me batty. The company I work for is already paying you for the service I'm using. We use SSO for EVERYTHING, I've already 2FA Authenticated the login, and even if I set up a passkey I will still have to 2FA the login.
I don't use these sites in any personal capacity, and I would never use a site that harasses me in any way if I was not absolutely required to in order to earn a paycheck.
You're not going to get any money out of me, why are you torturing me?
Passkey just suck, end of story. The UX for them is so bad. I have no idea how many active pass keys I have. I just have to trust the provider knows what they're doing. Sometimes my authenticator app seems to forget my pass keys which is even more annoying.
Stop the insanity.
So in other words, Passkeys are over engineered and simply too complicated for most users.
Succumbing to lock-in can smooth some (but not all) rough edges and creates it's own restrictions and risks.
TOTP for the win --- it's the simpler practical alternative.
TOTP is really annoying IMO but at least you control it so you can make it one-factor again if it's foisted on you. I made a Chrome extension to do that:
https://chromewebstore.google.com/detail/lazyotp/eoihmklnjkn...
Password + TOTP have served me well so far. To port from device to device I just need to log into my Bitwarden account. It is unclear to me what device loss would do to a passkey and the passkey never communicates that information to me. If I set up a passkey on my iPhone, the site prompts me on my Linux desktop. I understand it's fine for people who use single platforms for everything. But as far as I can tell there is no advantage over Password + TOTP. I really hope Passkeys don't become mandatory. I only use them for sites I don't care about or when I've accidentally said yes to setting one up.
Device loss:
If you had multiple devices set up on the site (each site must have done this individually), you just use a different device.
If you had synced your passkeys somewhere (note that the spec allows sites to block this, though I'm not aware of any actually doing so), you sync them to the new thing and log in normally.
If you did none of those, it's gone forever. Do the account recovery process, if one exists.
So it degrades to equal or worse than passwords in all cases (which cannot block backups or syncing, and you can enter them individually by hand so you're not exposing all your passwords to the device, and you can communicate them over the phone or in writing), for device loss purposes.
Restoring access in this scenario is imo one of their worst qualities.
I have been working with computers since 82, on the Internet since 88, on the web since 92 and in the IT industry since 97.
I have yet to see any solid, significant evidence that passkeys are materially more secure than a random 32-character password + TOTP 2FA.
If a site or app refuses to let me create my own login and forces me to use a provider, I’m not going to be a customer under any circumstances.
If a site or app refuses to let me use a password+TOTP combination (as in, it forces passkeys), I am similarly out.
That’s not to say I don’t use passkeys. I have them on my Microsoft accounts, for one. But that is only after I have fully set up the account, and that the account plays very nice with the Microsoft Authenticator app, even going so far as to do challenge-response auth in coordination with the app, and plumping TOTP up to 8 characters.
Will I switch to passkeys elsewhere? Not for some time to come. My passwords make use of the entire two-byte UTF-8 character set, in that less than ½ of all characters typically generated can be found on a U.S. keyboard. So long as websites don’t restrict password length to moronically short values, a 32-character password with 2,048 possibilities for every character ought to be reasonably difficult to crack.
And then, of course, comes TOTP 2FA.
> I have yet to see any solid, significant evidence that passkeys are materially more secure than a random 32-character password + TOTP 2FA.
I think the main selling point of passkeys is their ability to prevent phishing.
A 32-character password + TOTP can still be entered on a phishing website, e.g. if you happen to follow a fabricated link. With passkeys, this is not possible by design.
> A 32-character password + TOTP can still be entered on a phishing website, e.g. if you happen to follow a fabricated link.
…How? The password manager only permits exact links. If the URL does not have the UTF-8-identical characters to the correct url - at which time, IT IS the correct URL - it will simply not populate the username and password fields.
> I have yet to see any solid, significant evidence that passkeys are materially more secure than a random 32-character password + TOTP 2FA.
Not more secure, but some sites mandate email/SMS 2FA, don't support TOTP, and have added passkey support.
For these sites, using passkeys is materially more convenient than copying 2FA codes from email/SMS.
> some sites mandate email/SMS 2FA
Which should be made illegal on a national/international level.
The only possible reason for that is sheer laziness or malicious ignorance. Full stop, end of story
And I also include eMailed login links and eMailed 2FA in with that determination. Any secure login attribute that gets transmitted over eMail or SMS should be illegal. Password reset links, only. And vendor-locked/vendor-specific apps as the only 2FA path should also be illegal. TOTP should be a fully open system, letting anyone use any legitimate provider or app.
Yeah, let’s just say I have some pretty strong opinions.
Really great article.
I also think there's still an enormous ignorance from passkey devs that lots of people want to occasionally log into personal services from locked down corporate machines, and the flow to deal this is at best terrible but more often non-existent, and developers with typically enhanced privileges just aren't able to conceive how difficult this is.
Logging in to a personal service from your locked down corporate machine with a passkey works like this:
1. Start to login to the site.
2. When it gets to the point that you would choose to use a passkey if you were logging in at home, there should be some option that lets you say you want to use a passkey on another device. You can use that to tell it you want to use a passkey that is on your phone.
3. It gives you a QR code to scan with the phone, and then you complete the login using the passkey manager on the phone.
This is one of the core use cases for why FIDO Cross-Device Authentication was created. To be able to use a passkey to sign in on a shared device, a device you don't control, or a device where you just need temporary access to something.
On the one hand, that seems really important and I'm happy to know it exists.
On the other hand, I thought I had fully researched how passkeys work and literally never came across it.
So it kind of just continues to support my concern that passkeys are just too complicated to understand. If I'm at another device I need to log into, I would have just assumed I couldn't.
There needs to be a simple mental model for users. I'm not saying passkeys can't underlie that, but I think the UX still just hasn't been fully figured out yet.
I used the technical name for the capability, but you've likely run into it before.
If there is no passkey on the local device, a QR code will appear which you can scan with your phone or tablet, and use the passkey for the account from that device. It just kind of happens, typically without the user having to do anything special.
I will say though, corporate devices can be a bit of a wildcard as they are usually configured and locked down for a specific purpose. But the cross-device flow is generally not blocked by organizations.
I don't use passkeys, so I haven't run into it. It seems like that screen would be gated behind entering an e-mail address or username that is already registered with a passkey on another device.
What I'm saying is, I thought I had the right mental model of how passkeys work, after researching them, and that mental model told me you wouldn't be able to log in on a different device without going through a whole procedure to set up a new passkey, which you wouldn't want to do for something temporary.
The mental complexity is just too much for me to trust that if I adopt them, they'll work when I need them. The fact that I got this thing wrong means there's probably other things I'm still getting wrong.
I understand passwords and password managers and even 2FA. I feel like I can plan how to use them right so it all works and I don't need to worry about not being able to access my accounts. I just don't have that confidence with passkeys.
> log into personal services from locked down corporate machines
This is usually a bad idea, and is sometimes expressly forbidden.
But. more generally, there must be a flow for accessing your account when the passkey is not available, and possibly cannot be recovered.
I'm limited in what applications I can install at work. I am not limited in what websites I can access on my lunch break (within reason).
This is one of the core use cases for why FIDO Cross-Device Authentication was created. To be able to use a passkey to sign in on a shared device, a device you don't control, or a device where you just need temporary access to something.
Just tried that.
Logged into Passkeys.io on my phone, and created a passkey.
Then tried to log in to it on my Windows desktop, using the "With my phone" option. First time around it failed to connect to my phone. Future times it connected, but told me that the phone had no appropriate passkeys on it. At which point I gave up.
Edit: I then tried on GitHub, and it worked perfectly! Okay, that's pretty awesome.
As someone who has enhanced privileges, I'm having problems thinking of what all the the issues here are.
Corporate installs disable all USB functionality, and remove the ability to sync profiles? Something like that?
If you’re not using bitwarden or equivalent they can’t be moved off a device you own at all, and even with it you’d need to download bitwarden which might be impossible
Passkeys are fantastic for the vast majority of the population. They solve oodles of problems. No more teaching ${FAMILY_MEMBER} about good passwords, password re-use, trying to explain how to use a password manager, etc. Instead: create passkey, done. Then it's seamless login whether they're on their computer, phone or tablet.
As a tech-savvy user fully aware of the underlying machinations involved with passkeys, I greatly prefer their simple, fast login experience over: username submit password submit TOTP submit, and especially over the much-worse "we've emailed you a code" login slog.
It's great until they break their phone, or spill coffee on it, or just lose it, and now they are locked out of EVERYTHING with no good way to get back in.
Passwords on a piece of paper for better or worse do not have that problem.
Only if they're not backing up their phone, which seems insane in this day and age.
And even if they're not, if they have a computer or tablet, the passkey will still be available there assuming they share an account.
You can also recover your iCloud Keychain via a designated/trusted Recovery Contact (e.g. spouse, who presumably hasn't destroyed their phone at the exact same time), or via iCloud Keychain escrow.
https://support.apple.com/guide/iphone/passwords-devices-iph...
Both of the major smartphone companies (Google and Apple) have pretty robust account recovery processes. Are you familiar with all the options they have? Your comment gives me the impression that you are making assumptions about what would happen, instead of doing research on how it actually works.
I experienced Google's recently and it was very robust.
Even before passkeys, the average user would have major problems if Apple and Google didn't have good account recovery processes.
>with no good way to get back in.
which is why at the very least your email provider gives you a recovery kit to print out (the equivalent of the notebook) and if you can get back into that account you'll likely be able to get into whatever else you signed up for.
There's no difference here between passkeys and any other central storage be it a password manager or a physical notebook. If you lose that access, well you're screwed. But it always beats having hotdog123 as your password for 70 different sites.
Password managers can be backed up onto USB drives pretty easily, and copies can be made of paper.
It's much more difficult to make comparable backups of passkeys due to all the "anti phishing" / vendor lock-in rules most platforms have.
Android syncs them to your Google account and iPhone to your iCloud account by default. Which isn't a perfect solution but, again, is pretty good for most people.
And I just found out recently that you can't log into Google on a desktop without responding to a prompt on your Android phone. Which, if you broke said phone, you can't do.
This is without 2fa enabled on my Google account.
There are a few alternate options like email or sms (I've used them several times, you have no option if you erase your only actively-used phone occasionally), but yeah. Google effectively forces 2FA whether you like it or not.
I don't think this is correct
And that's great, as long as you're totally cool with access to _any_ of your accounts _anywhere_ being completely controlled by either Apple or Google.
I was just correcting the parent post that implied the passkeys were only stored on the device. Personally I do not use that feature.
I'm also pretty sure I don't have any accounts that can ONLY be accessed via passkey.
Have you ever been locked out of your Apple account?
Maybe because your kid was playing with your phone and kept entering the wrong passcode and now you’re locked out for several hours?
Or because Apple detests anyone else touching your phone and you’re traveling internationally and your screen cracked and you took it to a local repair shop which in the process of replacing the screen triggered something Apple didn’t like and you’re locked out for a decade.
You omitted my favorite feature: virtually immune to phishing. You can't accidentally submit a passkey to a lookalike domain.
For phishing protection, passkey as a single factor is better than memorized password + TOTP/SMS two factor.
How does the secret jump from the PC to their phone? How do they know each other? ...does the answer involve going all-in on Apple forever?
Your credential manager provides this sync and backup capability. There are dozens of credential managers available that work on all platforms. You don't have to use the default one on any given platform.
Bitwarden is my personal choice.
I still don’t like that I can’t use them on a computer that I can’t download bitwarden on. Library computer, etc.
Passwords I can see myself and make the informed decision to use temporarily somewhere else.
When was the last time you used a library computer, let alone logged onto a private service with it? This was a bad idea even 20 years ago. In today’s security climate, aw hell no.
Or my sisters laptop. & Fairly recently actually, to print something. Most accounts I don’t care that much about & two factor should be enough to save me I hope.
iCloud Keychain (or whatever the Google equivalent is). And as I said, it's a fantastic solution for the vast majority of the population (which, coincidentally, are also not Hacker News readers).
Can you keep access if they decide to shut you down?
https://news.ycombinator.com/item?id=46252114 https://news.ycombinator.com/item?id=42350245
They closed my PayPal account for TOS violation after donating to The OpenBSD Foundation. I wouldn't trust them as far as I could throw them.
Huh? I’ve seen zero implementations that work seamlessly across computer, phone, tablet - unless they are all single platform, which I have yet to see anyone actually pull off.
It's a beautifully simple experience for Apple users across all their devices.
I can't speak for other platforms; I stopped helping ${EXTENDED_FAMILY} with non-Apple questions because the crap I had to diagnose, debug and deal with for Windows and Android was worse than ${DAY_JOB}.
There are nearly countless ones - 1password for example works everywhere, as does Roboform, bitwarden, keepass, LastPass, nordpass, and many others.
All sync seamlessly and support the major (and often minor) browsers.
Google Password Manager, Bitwarden, 1Password among many others.
Everyone pretends that you're force to only have 1 passkey. I use 3 "passkey managers": Passwords.app, Bitwarden, YubiKey hardware key. I usually add all 3 or just two (skipping YubiKey).
On Apple devices I get neat experience out of the box, on Linux (+Firefox) I forced to use Bitwarden because Mozilla is being Mozilla.
Never had any issues ever with passkeys.
3 technological devices which I can't validate by checking if the physical piece of paper is still legible in a safe.
Yep. I use Apple’s direct support which works out of the box. I also create a second passkey in 1Password. And for truly important accounts (1Password itself, Apple, Google), I have a third copy on a YubiKey stored in a safe deposit box.
I feel like a boomer.
I dont want to use google/apple/microsoft for any credential manager because: google is evil; apple has locked me out of my apple id (and lost things like the recordings of conversations with my father during his hospice); microsoft keeps getting worse and more annoying to use.
So ok, I need some credential manager. I used keepass previously... but how do I vet other credential managers? I dont want an online backup. I want my credentials to only be on my computers. So now I gotta learn about which apps are ok, don't have cloud synching, can export files, and be compatible with MacOS.
And I have to learn what is FIDO? Like FICO? why do I need to synch with FIDO? what is it? will it give my credential store to others?
How is this easier or more convenient than a user/pass with 2fa?
I feel like I am going to accidentally leak my credentials and have no way of knowing
> I dont want an online backup. I want my credentials to only be on my computers. So now I gotta learn about which apps are ok, don't have cloud synching
If an "online" password manager uses end-to-end encryption, then the credentials really are only on your computers. The only thing "in the cloud" is encrypted blobs of data being moved around for the purpose of device sync and backup.
This insistence on using local non-syncing password managers is a masochistic exercise in making life difficult for yourself with no security benefit.
That came across more snarky than I intended!
Let me rephrase: for the majority of users, the usability and resilience benefits of synced credentials are enormous, and the security costs are marginal at best. But this rests on a number of assumptions. YMMV.
In your case it's literally the same "complexity" as user/pass with 2FA. You need something to manage the passkeys, just like you need something to manage your second factor. Everything else you list as a worry is already in play.
FIDO is a standards body which produces specifications used by these systems.
One thing I genuinely hate about modern tech is that it punishes you for planning ahead. I purposely spent time getting a password manager and implementing 2fa protocols that would both speed up my time and keep me safe. Then suddenly every company decided it was time to go passwordless or do passkeys and all my work (researching different products, setting each one up, making sure hey work on all my devices, etc etc) suddenly goes down the drain
Passkeys need a marketing campaign and UX overhaul.
I’m a technical guy, but I really don’t understand what the fuck is going on when I use a passkey. All I know is one day it appeared as an option and it let me login to things. I don’t really understand where it lives, what device it’s tied to, how scanning a QR code on Google Chrome on my phone magically logs me in, etc etc.
The user was not educated on this. Hacker News is the top 1% of computer power users. You gotta understand to someone’s grandma or mom or brother who works in real estate none of this makes any sense nor will they educate themselves on what it is.
How do you use your passkeys? Do you have them sync with your apple or google accounts?
I've only experienced using passkeys with 1password and it's smooth as butter. Assuming 1p is unlocked, To login: press login with passkey on website -> press sign in on 1p extension pop-up -> done To create account: click create passkey on the website -> click save on 1p extension pop-up -> done
Tbh i think it's more important to get people to use password managers than passkeys.
when you create or use a passkey, the UI on all platforms tells you where it is going to be saved or where it is coming from.
Right now, when I go to the security section of my Amazon account in Chrome, it (unasked) prompts me to add a passkey, and the popup on my Mac says, verbatim:
> Add a passkey? "amazon.com" supports passkeys, a stronger alternative to passwords that cannot be leaked or stolen. A passkey for "xxxxx@xxxxx.com" will be saved in "Passwords". Touch ID to Save Passkey Cancel
I don't have the slightest idea what "Passwords" is as the destination. My iCloud keychain? My Google account? My 1Password?
Passwords is the name of the app on your Mac.
OK, on the one hand TIL -- thank you! That's a super-meaningful piece of information.
On the other hand, you can understand why that is not remotely clear from the message. It's a generic term in quotes. If it said it would be saved "in the Passwords application (and synced to iCloud)", then I'd actually understand it.
So Apple is either being intentionally obtuse or incompetently confusing here, and I don't know which is worse. And it's UX crap like this which is why I still won't use passkeys, because I don't know where anything is going.
I can certainly see the confusion. Thanks for highlighting it!
Exactly passkeys are confusing to the laymen (and not Laymen) because it’s is an orchestration across multiple services and devices.
If I’m using a passkey to login to my Gmail via chrome browser but used my phone what just happened - did it save in chrome? My Google account? My iPhone?
The dialog provided by the browser or OS usually tells you where the passkey is saved.
Totally agree with this. Passkeys are a solution but not the sole solution. There is absolutely a misconception for seeing them as newest and therefore the best choice.
Hmm, does not mention that you can't use Passkeys if you don't have JavaScript enabled.
It's not really passkeys that are the problem, it's trusting your passkey to a third-party. But this is still a minor part of the market today, a much bigger problem to warn people about is the "log in with your google/facebook/etc account". Where you're handing everything over to a third-party as well, because it's so easy and convenient.
Passkeys, stored in Bitwarden, give a lot of the same convenience, but without the vendor lock-in. We shouldn't be scaring people away from passkeys, when commonly used alternatives are much worse.
It's the fact that there's no physical artifact that's the problem - there's no file.
You can't back up your passkeys and wind up with something you put in a safe on a USB key or something and vendors have been aggressively trying to make that harder.
You can export them from Bitwarden and back them up.
Passkey is a great avenue for hackers because they represent an optional authentication mechanism that users overloook.
I update a spreadsheet with all my accounts and money and their values so I know my net worth and its changes, and oh boy every month getting these numbers is such a chore.
Since it's been a few days, sometimes I am logged out of either bank/traders and also the password manager.
So it's open the bank site, click on login/password, password manager browser extension asks to login. Type password manager password. It asks for 2FA. Unlock phone with face. Find app, open app, unlock app with face. Approve password manager login. Click on bank login/password again. I am in! No, bank wants to 2FA with mobile. Unlock phone with face. Open bank mobile app, unlock with face. Get code or approve login. Back to computer, type code or click approve.
Repeat that 12 times for all the accounts, and by the end of it I have neck pain with all the "pick up phone to face unlock" motions.
I am a bit paranoid so I turn on 2FA and passkeys and whatnot, but all of this makes me want to use `123password` everywhere and never change it.
For me everything goes in Keepass. And the only thing I want in life is the ability to change a password from Keepass in a standardized way.
Instead we've got Passkeys and the general promise by omission that I will be banned from using Keepass to store and backup my passwords as I see fit on my own devices.
People want me to trust the corporate overlords who at every turn have practiced lock in and rent seeking tactics.
Related: I released a hosted sign in page for passkey auth today.
Take a look:
https://passkeybot.com
I'm tired, boss.
[dead]
Passkeys are a completely seamless experience on Apple platforms in my experience so far.
Not that seamless if you do not want to be locked into a single platform, though. This is what the article mostly talks about.
Why are you locked into a single platform?
I use bitwarden, Google and a yubikey for passkeys. Which of these am I locked into?
Apple has offered an “iCloud for windows” app for ages that literally syncs your iCloud Keychain (passwords and passkeys) to a windows box where you can use browser extensions for chrome, edge, etc.
You’re still not platform locked…
The biggest problem I have with passkeys is being tied to a single device you still need a flow to reset/get in _without_ the passkey. As you're only as secure as your weakest link passkeys don't add any security.
That said, if you have a mac with a fingerprint scanner they sure are very convenient option.
And don't get me started on terrible vendors like Rippling that only support a single passkey! Madness.
I dropped my phone and it literally fell apart. As a result I have been locked out of my AWS account. The get a phone call verification just does not work. Only saving grace is that it was an account I used to test things.
I keep hearing it repeated, but where does this "tied to a single device" idea come from?
The default, built-for-the-masses implementation of passkeys is called "synced passkeys". They are designed to sync between all your enrolled devices, ideally using end-to-end encryption.
You authenticate with whatever device you happen to be using at the time - phone, tablet, laptop, desktop - doesn't matter. If you lose one, you replace that device and re-enroll - then all your passkeys magically re-appear on the new device.
If you're cross-platform, modern password managers work across ecosystems - for example, 1Password syncs passkeys between Mac, Windows, iOS, Android, and Linux. If you're all-in on Apple, their native passkey implementation syncs passkeys between all your Apple devices. I thought Google and Microsoft do something similar now.
It's a real mystery why people believe passkeys have to be stored on your phone only.
If I use windows at home (gaming), mac at work and android on my phone - how exactly are these supposed to seamlessly work together?
There are many cross-platform password managers that sync very nicely, which would solve for the machines you control - the Windows gaming machine and Android phone.
For machines you don't control, such as your employer Mac, well that's a special case. In theory you can use "FIDO Cross-Device Authentication", which is a passkey flow designed specifically for authenticating on one device using a passkey stored on a different device, and involves scanning a QR code.
I've never tried this though. Personally I tend to avoid mixing personal stuff with work stuff, so the problem rarely arises.
Because by default, they do, and you have to explicitly install software to let it be moved. And even if you do, it’s discouraged and the spec is allowed to deny you access.
This is not correct. The default credential manager on all devices except for Windows, creates synced passkeys. And Windows will be changing soon.
Synced to one ecosystem tho. I don’t care if Microsoft deigns to let me use it across all of my devices they own.
Passwords I can bring anywhere.
Not exactly. For example, the default credential manager on Android is Google Password Manager, which works on Windows, macOS, iOS, and Ubuntu. There are also dozens of other third party choices.
> it’s discouraged
Why do you say that? There are billions of synced passkeys being used by users with some of the largest sites and services in the world.
Last I heard, they were pushing hard for resident keys only, maybe that's changed. I don't like that there's still the option to restrict it to that in the same way having the option to force remote attestation makes me uneasy.
A passkey is a discoverable credential (aka resident key) in spec terminology. But the type of credential has no relationship to attestation (which is not used in the consumer passkey ecosystem).
Ah my bad, I thought the distinction was resident = stored on a YubiKey/Secure Enclave/TPM and that was what made them resident.
To my credit I think yubikey uses the term that way and webauthn has a different definition but in the context of passkeys you’re right.
Just to point out, protecting a key using the secure enclave and syncing it using end-to-end encryption aren’t necessarily mutually exclusive.
The security property you care about is that the plaintext key is only ever processed in use within the secure enclave (transiently, during authentication).
That doesn’t preclude syncing or backing up the encrypted key via a cloud service - if the device allows the application to do that.
Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.
How do the decryption keys for the encrypted passkeys get shared between devices?
>Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.
I wasn't referring to hardware keys (like YubiKeys), but rather on-device secure enclaves, TEEs, or TPMs.
Also I said "protecting a key using the secure enclave", which is perhaps a bit of a sleight of hand :-)
By that I mean a key that is wrapped (encrypted) using a parent key stored in the secure enclave. The key itself is not stored in the SE. But since it is wrapped using a parent key that is stored in the SE, that means it can only be decrypted in the SE. I believe this is how iCloud Keychain works, for example.
Digging into this further, it looks like I might have been wrong to imply that a credential manager app can instruct the SE itself to perform the proof of possession calculations needed for passkey authentication using a private key that is "protected" in this sense. When the app asks the SE to decrypt a passkey private key, it looks like the SE might return the passkey private key in plaintext to the app, and then the app itself performs the proof of possession calculation transiently outside the SE. I'm not sure about that, but I'd love to know.
> How do the decryption keys for the encrypted passkeys get shared between devices?
They get established as part of the device enrolment process. I suspect this simply adds another layer to the key hierarchy, so that your passkey private keys are encrypted under a sync key (parent) which is encrypted under a SE key (grandparent).
In that case, you could still claim that your passkeys are "protected by the SE" since they are encrypted at rest and in transit, and they cannot be decrypted anywhere except in the SEs of your enrolled devices.
> stored on a YubiKey/Secure Enclave/TPM and that was what made them resident.
Stored in an authenticator/credential manager in general, not specific to a security key, secure enclave, or TPM.
> Because by default, they do, and you have to explicitly install software to let it be moved
Apple's native passkey implementation doesn't require doesn't require you to install extra software, and the passkeys sync by default. I thought Google's and Microsoft's were similar - but I haven't tried them.
> And even if you do, it’s discouraged
Really? Where is it discouraged? I thought synced passkeys are intended as the solution for consumers.
> the spec is allowed to deny you access
Yeah but I thought that's for enterprise use cases, not consumer. E.g. employers that want to enforce device type restrictions on their employees.
It does if you want to share accounts between my iOS phone and Linux desktop. And it still puts you entirely at the whims of Apple, etc. if you’re allowed to log in to unrelated accounts.
& I think it is mostly being used for enterprises for now ,but much like TPM and remote attestation running on “my” computer, I don’t like that it’s an option
starting to really hate these, regret ever using one
I don't care what you other people in auth do, I work in auth too, please stop making signing into anything 5 steps.
1. First I get redirected to a special sign-in page.
2. Then I sign-in with my email only.
3. Then it finally asks me for a password, even for services that would never reasonably use SSO or have another post-email receive process.
4. Then I get redirected again to enter 2fa.
5. Then these websites ask if I want to create a passkey. No, I never want to create a passkey, and you keep asking me anyway.
6. Then, and only then, do I get to finally go back to using the service I wanted, and by then, you've lost whatever my `?originalUrl=` was, and I have to find it again.
No, don't send me a magic link. Because then I have to go do 4 more steps with Gmail or another mailbox provider and now signing in has become 10 or more steps.
No, don't tell me getting rid of passwords will help most of the population, and then force all of us to do the above, and blatantly lie to us that it's better.
Stop it. Get some help.
I still find myself stuck on step 0: find the fucking log in button that is for some reason tiny/looks disabled/not easily discernible as a button
[dead]
If you created a passkey, it would be one step.
[dead]
Please don't use fixed-width fonts to write text. Please use fixed-width fonts to write code.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
(quoting https://news.ycombinator.com/newsguidelines.html)
I think part of the distress experienced by readers is due to mixing the fixed-width font with "text-align: justify". So it's close but not exactly fixed/consistent.
Ah, thank you for pointing that out! I was wondering what it was.
Firefox Reader Mode makes such sites more readable.