jesseendahl

>if they didn't remove sharing/export functionality that Google, Apple and others had at the same time.

This is factually incorrect — no one supported exporting passkeys at the time and I believe the only ones who supported passkey sharing of any kind was Apple: https://support.apple.com/guide/iphone/share-passwords-iphe6...

What that Keepass X GitHub PR comment section was discussing was giving users a way to export their passkeys to an unencrypted file on disk, which would have allowed for attackers to convince non-technical users to export all their passkeys and then send them to an attacker.

I believe person who commented on that GitHub PR was trying to explain that instead of implementing export to plaintext file on disk, it would be a better idea to implement the Credential Exchange Protocol, which was almost finished at the time.

https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20240522.html

Fast forward to today... and it looks like there's movement towards doing exactly that:

https://github.com/keepassxreboot/keepassxc/pull/13343

--

Edit: Indeed if you scroll down to the last comment on that infamous PR (https://github.com/keepassxreboot/keepassxc/issues/10407#iss...), you'll see they closed it in favor of implementing the Credentials Exchange standard.

- Having principles and sticking to them is not opposing.

- Just because you don't do everything someone wants you to do does not make you a supply chain risk.

Are you describing the plot to Pluribus?

People treating their political party as a “team” is one of the biggest problems we have right now as a society, so I find this language of “red team” and “blue team” extremely concerning.

Yubikeys generally have much worse recovery scenarios than passkeys do, for consumers. In enterprise if you lose your yubikey, an IT admin can help you get back into your account. If you lose a security key as a consumer, you're generally in a much tougher account recovery situation.

>He didn’t remember his password, and we were unable to reset it because you need the passkey! No other options to authenticate for a reset were available.

Google treats both a password and a passkey as a primary factor, and if you forget either of them you have to go through their account recovery flow: https://support.google.com/accounts/answer/7682439?hl=en

AFAIK there's nothing different about the recovery scenario for a Google account in that state regardless of whether it has a password in use as its primary cred, a passkey in use as primary credential, or both.

Account recovery works the same with passkeys as with passwords. You click “I forgot/lost my passkey” and get a link sent you via email that lets you create a new one.

Passkeys can also be shared with other people like spouses or friends, just like passwords.

Majority of second factors are phishable. If you are using a password (phishable) + a phishable second factor (any kind of 6 digit code that you need to type or paste into a text box), you are less secure than if you were using only a passkey.

>They want you dependent on them and locked into their ecosystem.

This is a strange conclusion to come to when clearly a lot of effort was put into developing an open standard (Credential Exchange Format) to make it easy and secure to move credentials between vendors/ecosystems, without opening end-users up to phishing attacks on credential export.

If big tech wanted to lock people in, it seems like it would have been a lot easier to just... not create an open standard.

>I thought the point of storing secrets in hardware TPM and not giving them out into userspace (i.e. passkeys instead of passwords) is protecting against malware as well.

This was never a design goal of passkeys as far as I'm aware, and normally passkeys are not generated or stored in a TPM. The primary design goal of passkeys was to make a phishing-resistant primary factor that could compete with the user experience and convenience of passwords, so that folks would actually be interested in using them.

I think you are thinking of security keys, which generate key material in e.g. a YubiKey which offer similar protections to a TPM.

YubiKeys can also be used to generate/store passkeys, but when they are used for passkeys typically they'd be referred to as "device-bound passkeys" rather than just "passkeys".

Password managers do not architecturally, cryptographically make phishing impossible. Ultimately a user can still be tricked to copy/paste their passwords into fake websites, even when using a password manager. You could blame end-users for this behavior, but attackers don't care about blame. Ultimately, it doesn't matter who's at fault when there are massive phishing attacks happening at scale every single hour of every day. The only real solution to solve this problem for the entire internet is to make credentials architecturally, cryptographically unphishable by design. That's what passkeys give you.

Passwords are still significantly less secure than passkeys even when using a password manager.

I like it.

The high level UX of this idea feels very compelling to me as a "yes and" -- aka a world where vendors continue to offer end-to-end encrypted syncing within an ecosystem, but then this idea gets layered on to solve the cross-ecosystem problem. I think the trickiest part would be how to do it in a privacy-preserving way, but that's solvable.

> I don’t see hardware tokens (like Yubikey) in the list. Those are the only ones that provide a true second factor

passkeys are not meant to be a second factor; they are meant to replace the password as a primary factor.

>to protect against the theft or compromise of your primary device.

I love Yubikeys, but the only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential.

But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session.

And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/

I have no idea if Yubico is involved with DBSC, but I would hope that they are, because it would help them make Yubikeys live up to the security guarantees that I personally feel are heavily implied by their marketing.

There are some parts of this that are correct and other parts that are incorrect:

>1. The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing).

This is incorrect. The idea was to provide a phishing resistant primary factor that could compete with the usability of passwords to the point that consumers would actually want to adopt it.

>2. Majority of industry players shared the vision of a credential which is available across the platforms and browsers

This is correct/accurate.

> 3. The vision for collaboration never materialized so everyone went their own way to implement it. Examples would be google rolling out browser (Chrome) managed authentication which led to this situation where even on the same machine you have to remember which browser you used to create the Passkey credential.

IIRC at least Chrome's default on Apple platforms is to save to the Passwords app by default. There are then multiple fallback options in the case that the user isn't using the default credential provider -- ultimately falling back all the way to cross-device passkey sign-in (the QR-code initiated sign in) or Security Key.

The security engineering behind the QR-code cross-device sign-in stuff is interesting: https://www.corbado.com/blog/webauthn-passkey-qr-code#4-pass...

That said, I strongly agree that fragmentation of where passkeys get saved is super confusing and I wish there:

(a) was stronger guidance from the FIDO alliance on both educating users that it's totally fine to have multiple passkeys across different ecosystems (e.g. one in Apple, one in Google), and;

(b) that all the credential managers could figure out a better way to place nice together and make it super clear to the end-user where a passkey is getting stored, what context it's for (e.g. personal vs. work), and actively help them store it in the right place (which might be different credential manager app for personal vs. work!).

> 4. Interestingly enough the earlier popular name was WebAuthn, Apple started calling it Passkey on fly, given Apple's popularity everyone just caved in.

This is incorrect -- passkeys are not just another name for WebAuthn. If you go back and look at the original definition Apple gave for the word passkey, you'll find that it was meant to be a discoverable WebAuthn credential that syncs across a user's devices with end-to-end encryption. There was a bunch of industry thrash around the definition, but it seems like the original Apple definition has largely stuck/settled now, and when passkeys don't sync they're typically called "device-bound passkeys" rather than just "passkeys".

>5. My personal interpretation is that in some sense Apple wanted to be the default password manager on Apple devices.

If you go back and watch the original passkeys announcement from Apple, their stated goal was to create something that is both a better user experience and more secure than passwords. By "better user experience", they meant the act of creating credentials and then repeatedly using those credentials (logging in).

Part of actually achieving that goal means there needs to be something that "just works automatically out of the box" which means there needs to be a built-in credential manager. That said, Apple credential manager had already existed for many many years by the time passkeys came around. The only thing that changed was instead of being solely accessible from inside System Settings (which was hard for the average user to find), the functionality moved into a standalone Passwords app.

>6. This is when all password manager companies jumped in strongly to save their business and the protocol went into a direction where you can use your existing password manager to store the credential/Passkey as well

I think it's a huge positive that all the password managers jumped on board, and that they could jump on board (since WebAuthn is an open standard). I think this is a good thing for consumer choice and for overall adoption and perception of passkeys. A lot of folks (including on this thread) have big tech lock-in conspiracy theories about passkeys, and the conspiracy theories would be even more prevalent without a wide spectrum of consumer choice for credential managers.

>If you are using it with security in mind then my recommendation would be to use a hardware backed security key with NFC enabled. Everything else is pretty much lipstick on pig, they are worse than passwords in some sense from usage perspective.

Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation.

The only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential. But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session.

And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/

This is the #1 most common misconception I see about passkeys. They do not make it more likely that you will lose access to your accounts. They actually have nothing to do with account recovery. They are just a stronger primary factor than a password.

Most providers continue to offer email-based recovery in the case that the end-user loses access to their primary factor, regardless of whether the primary factor is a password or a passkey.

And email based account recovery does not make the security advantages of passkeys disappear, which are:

- credential that's guaranteed to be unique

- credential that's guaranteed to be strong

- credential that cannot be phished (due to cryptographic binding to the domain at the time of credential creation)

- changes the incentives for compromising servers (there's nothing worth stealing from the server -- only public keys)

- if/when an app/website transitions to retiring password-based authN, then it will entirely eliminates credential stuffing attacks

And if the account recovery scenario in question is your Gmail or Apple account, then you would need to go through their account recovery flows regardless of whether you were using a password or a passkey:

https://support.google.com/accounts/answer/7682439?hl=en https://support.apple.com/en-us/118574

>Passkeys and 2FA are a usability nightmare if you need to recover, or all the security vanishes if you put usable recovery mechanisms for the passkey or the second factor.

Most providers continue to offer email-based recovery in the case that the end-user loses access to their primary factor, regardless of whether the primary factor is a password or a passkey.

And email based account recovery does not make the security advantages of passkeys disappear, which are:

- credential that's guaranteed to be unique

- credential that's guaranteed to be strong

- credential that cannot be phished (due to cryptographic binding to the domain at the time of credential creation)

- changes the incentives for compromising servers (they're nothing worth stealing from the server -- only public keys)

- if/when an app/website transitions to retiring password-based authN, then it will entirely eliminates credential stuffing attacks

> Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound

If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case.

What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple.

The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.

This part of their requirements for how PCC is architected directly addresses your concern:

“Verifiable transparency. Security researchers need to be able to verify, with a high degree of confidence, that our privacy and security guarantees for Private Cloud Compute match our public promises. We already have an earlier requirement for our guarantees to be enforceable. Hypothetically, then, if security researchers had sufficient access to the system, they would be able to verify the guarantees. But this last requirement, verifiable transparency, goes one step further and does away with the hypothetical: security researchers must be able to verify the security and privacy guarantees of Private Cloud Compute, and they must be able to verify that the software that’s running in the PCC production environment is the same as the software they inspected when verifying the guarantees.”

No, it is not. And if you fall in love and want to get married to someone on a student visa, your fiancée should not need to leave the country for a year or two to wait for paperwork to process. Which is one of the real world impacts of this change.

This is true at companies that treat security as a checkbox driven by compliance.

Not true at top-tier tech companies building software in product categories that by their nature have very high security requirements, like Fintech (e.g. Coinbase, Mercury bank, Wise).

There are so many bots/trolls on HN now, it's crazy.

What do you mean “just tap and hide a SMS”? Maybe my brain isn’t fully booted and I need more coffee, but I’m not understanding what this means.

This story was recently on first page of HN:

https://techcrunch.com/2026/03/18/fbi-is-buying-location-dat...

This is the bill referenced at the end of the TechCrunch article:

> Last week, Wyden and several other lawmakers introduced a bipartisan, bicameral bill called the Government Surveillance Reform Act, which among other things would require a court-authorized warrant before federal agencies can buy Americans’ information from data brokers.

Previous HN discussion about the TechCrunch story: https://news.ycombinator.com/item?id=47430797

You don't need to use anything from Apple/Google/Microsoft. Passkeys are just WebAuthn which is an open standard.

Passwords are terrible UX for old people in my experience. They try use the same password everywhere, but then password complexity requirements mean they can't use the exact same password everywhere, and then they forget which variant they used on which service, so they just end up going through the reset password flow every time they sign in. I am not convinced that's a better UX than them just using their fingerprint or face to login.

>They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck

This is the biggest myth/misconception I see repeated about passkeys all the time. It's a credential just like your password. If you forget it, you go through a reset flow where a link is sent to your email and you just setup a new one.

And if it happens to be your Gmail account that you're locked out of, you need to go through the same Google Account Recovery flow regardless of whether you're using a password or a passkey.

I am not sure if you missed my earlier comment, but it's directly applicable to this point you've repeatedly made:

>If Apple believes this class of attack is no longer viable, that’s worth stating.

To say it more directly this time: they do explicitly speak to this class of attack in the keynote that I linked you to in my previous comment. It's a very interesting talk and I encourage you to watch it:

https://www.youtube.com/watch?v=Du8BbJg2Pj4

Apple's head of SEAR (Security Engineering & Architecture) just gave the keynote at HEXACON, a conference attended by the companies who make Pegasus such as NSO Group.

That doesn't seem like avoiding the elephant in the room to me. It seems like very much acknowledging the issue and speaking on it head-on.

https://www.youtube.com/watch?v=Du8BbJg2Pj4