Ricky Mondello responds to "Passkeys are a trap. Do not use them."
hachyderm.io
hachyderm.io
I agree the original post isn't great, but at its heart it's a rant about an unsolved problem: some applications need proof the key is kept secure, the only such proof FIDO provides is attestation, but in current solutions attestation is either absent or weak, or is strong but locks you into a single vendor.
Ricky is right the post is woolly, but if the principal software engineer at Apple's Authentication Experience team can't respond by telling us how they plan to solve the issue the post is about, it's an unconvincing rebuttal.
You can allow multiple attestations GUIDs (AAGUIDs) if you want, you're not limited to the larger hardware providers (ie: Yubico).
So far the only place I encountered this is within our Microsoft Entra setup, where we have to option to allow all types of Passkeys (hardware-backed, cloud synced, non-attested, etc).
Also in some scenarios you might be required to limit the enrollment of Passkeys on hardware devices that are FIPS-compliant. Having a list of AAGUIDs to enforce this makes sense.
I don't think they intended to make any argument that passkeys could be a trap to service providers.
Forgive me, but that’s not convincing. The post even admits that it is entirely possible to do it. It just says that it will “antithetical“. Many antithetical things have been done in the past. It won’t be the first.
These bodies need industry involvement/support (I've worked in similar WGs at both Red Hat and Microsoft), but it's very easy to engage in behavior that could easily be ladder-pulling.
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.
What exactly is the practical difference between "sharing" a key and "exporting" it?
As it is, Apple's Passwords app as of today absolutely allows importing and exporting of Passkeys ("Transfer to another app").
> 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.
This is a very diplomatic presentation.
This was in Tim's very first reply:
> To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406).
> I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
> Asking you to put basic protections in place and collaborate with the ecosystem/industry is hardly "anti-user-choice mentality".
"Sure would be a shame if the industry had to block your tool from our standard."
> which would have allowed for attackers to convince non-technical users to export all their passkeys and then send them to an attacker.
I mean, if you can convince a user to do that, there's not much more needed to say "and you can set a password on the encrypted export so it's all secure!" and get an encrypted export too.
> Fast forward to today... and it looks like there's movement towards doing exactly that:
Oh, it only took 2 1/2 years. Most of which was waiting on the FIDO Alliance to actually define a standard:
> > I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.
> There are hundreds of encryption options to choose from. Sure, we can choose AES-256-GCM. To what end? If no other product implements that encryption option, then exporting becomes worthless for portability.
> Define the standard first (just pick one or two), then publish it. There is no need to spend time debating the choice, plenty of great options to choose from.
Indeed, at the time:
> This is out of scope for the protocol and data format. Neither -and to use the working names here- CREEP (CREdential Exchange Protocol) nor CEF (Credential Exchange Format) should make any determinations about how the importer, exporter, or platform should store their keys, but we'll say that it should be secure.
But Tim didn't mention any such thing. As to this claim:
> it would be a better idea to implement the Credential Exchange Protocol, which was almost finished at the time
"was almost finished"?
CXP is still in "Working Draft" status as of today, where it has been for 2 years.
CXF (the format) is a "proposed standard" as of today.
I read it as "your actions might push relying parties to use attestation to be able to block you", not as "we, the FIDO consortium will block you". (How could they? There's no signer identity to block without attestation!)
That said I don't agree with the substance of the comment; it's effectively an appeal to security by obscurity/unavailability of user-friendly insecure export methods.
They claimed to work on the implementation of passkeys and basically told me I was being paranoid.
But it's not paranoia when they're actually out to get you. No one else interacted with that post. It did not become viral in any measure. I'll never voluntarily use a passkey, and I'd rather use a different service or none at all rather than use one that forces me to use a passkey.
Windows 11 rolled out with a required minimum TPM 2.0 as a way to force upgrade hardware, including threatening security updates. HN talked about it for weeks. It caused a mass exodus from Windows to SteamOS for many gamers.
While I agree this isn't a conspiracy, it is an open secret that these companies on the Alliance historically make and use standards to their own gain and against their users. It is the same with citizens relationship with governments, which comes with a long history of brutal repressions by the very agencies on the Alliance. This comes especially under the microscope when those tech companies collude with those Agencies against domestic citizens.
The trust is not there.
What's funny is that Passkeys are running into the OIDC problem again where everybody and their dog wants you to use their own implementation. The Costco app keeps bugging me to set up a passkey, and comments on the other HN thread have more examples [0]. It's just a mess. It's ironic the little inter-company territorial spats that keep the big conspiracies at bay.
On the other hand, I'm helping more people around me onboard into password managers. The number of accounts people have to juggle nowadays makes this a security mess too. Having one centralized place where all the accounts are stored (and backed up) is often a bigger boon for people than the secure passwords!