Ricky Mondello responds to "Passkeys are a trap. Do not use them."

30 pointsposted 8 hours ago
by latexr
(hachyderm.io)

12 Comments

rstuart4133

4 hours ago

Not a great rebuttal.

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.

JamesLeonis

34 minutes ago

> The post is predicated on the idea that a feature of WebAuthn called “attestation”, which is only used in high-assurance and usually corporate scenarios, and usually with physical hardware security keys, will be leveraged to hurt people, somehow.

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!

[0]: https://news.ycombinator.com/item?id=50048775

user

6 hours ago

[deleted]

dmitrygr

5 hours ago

Basically it boils down to “trust us, we won’t do what this guy is warning you we might do”

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.

lxgr

4 hours ago

No, the post in question just has really poor reasoning, and this one rightfully calls that out.

FireBeyond

4 hours ago

There was a member of the FIDO Consortium in a Keepass PR comment section implying that they would blacklist Keepass as a "responsible party" if they didn't remove sharing/export functionality that Google, Apple and others had at the same time.

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.

jesseendahl

3 hours ago

>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.

FireBeyond

43 minutes ago

> no one supported exporting passkeys at the time and I believe the only ones who supported passkey sharing of any kind was Apple

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.