Passkeys Attestation Trap
16 points by kaimac
16 points by kaimac
And even if the website doesn’t require attestation now, simply by using passkeys you indicate to the website that your setup supports the FIDO Alliance’s passkey standard and that you as a user are capable of using passkeys. This means that once Twitter (formally X) is satisfied that the overwhelming majority of its users would be unaffected, they can flip the switch [...] and start rejecting non-attested passkeys.
I know, there's a long argument in the quoted post about passkeys being pushed at least in part as a convenience, so that you pay the least attention to it, and pick the default settings. But this paragraph confuses unattested passkeys with the remotely attested ones, in a post that went to great lengths to explain the critical difference. That's quite the shortcut.
Here's the remedy to stop the corpo to bait and switch: don't use remotely attested passkeys. Stay away from Yubikey or whatever secure enclave the two mobile giants may come up with, and use something like KeepassXC or the TKey instead. Doing that will indeed signal that you're capable of using passkey, but each unattested user is a user the corpo may lose when they switch.
The real menace here is the possibly widespread use of whatever default passkey mechanism is around. From there there's an easy path to remotely attest those, then check the attestation without enforcing it, then when enough users are attested, switch to full enforcement. There are various ways to fight this, we don't have to give up on passkeys altogether.
We probably need a catchy naming scheme to distinguish the passkeys that serve the user, from those that serve our corporate over--I mean, the website you're logged in to. Both have their place, but it is critical we know the difference at a glance:
Here's the remedy to stop the corpo to bait and switch: don't use remotely attested passkeys. Stay away from Yubikey or whatever secure enclave the two mobile giants may come up with, and use something like KeepassXC or the TKey instead. Doing that will indeed signal that you're capable of using passkey, but each unattested user is a user the corpo may lose when they switch.
The concern broadly is that the typical user will just use Google/Apple/Microsoft because that’s what the modal dialog that interrupted their login flow told them to do, and not understand the consequences, and eventually sites (most likely banks first with their track record of “if the right people argue something is more secure, they will enforce it”) will block non-attested passkeys as something that just used by a few nerds.
A lot of criticism of passkeys is already deeply dishonest, but I think this one sets a new low.
From the post:
I believe this is not the goal of Mondello and some of the others working on this, but so far I’ve not been convinced that they will be able to control it. It sounds like Apple is working on it
If you go to Mondello's site and read the résumé publicly linked there, you will see the current job title listed: "Principal Software Engineer, Authentication Experience team" at Apple, described in part as
Developing industry’s roadmap for passkeys by collaborating in FIDO Alliance and W3C; serving as Apple’s alternate representative to FIDO Alliance board
So, on the one hand we have the Principal Engineer at Apple who literally works on the stuff giving strong direct quotes saying that this isn't what Apple or any of the other vendors want. And we have the evidence of Apple's actual implementation to look at.
But on the other hand, we have people who know they won't get clout and clicks unless they give you something to be afraid of. Notice how so many things in the piece are linked and attributed, but then suddenly and mysteriously no evidence or citation whatsoever is provided for the author's comment that "it sounds like Apple is working on it"? That's a big, big tell.
Michael Tsai should retract this hit piece immediately and apologize to Mondello.
While I don't think this is the goal currently, or likely to be abused, let's be honest about corporations. The goals of leadership now is not guaranteed to stay frozen forever. The public communication isn't even necessarily the truth in many cases. Sometimes standing against the capability itself is a good idea even if we get promised how it's going to be used. Kind of like we can be against mass surveillance even if there are promises and regulation in place - it's only a matter of time until someone changes the rules or doesn't follow them.
So I think the author is hopefully wrong, but also I see where they're coming from and I would be happy to see the passkey attestation out of the usual specification and instead part of some passkey-enterprise standard implemented in only internal systems.
let's be honest about corporations
OK, let's be honest. I do not believe that the goal of Apple is to destroy freedom and "general-purpose computing". I believe the goal of Apple is to make money. To the extent that they've, say, produced and sold devices that are more locked-down than some people on tech forums would like, I believe they've done so because they identified a market niche--people who want what is essentially a computing appliance, with fewer headaches and worries about security--that could make them a lot of money, and their balance sheet appears to back that up.
The goals of leadership now is not guaranteed to stay frozen forever.
But Michael Tsai is not saying that Apple could hypothetically turn evil some day in the future. Michael Tsai is saying: "It sounds like Apple is working on it". Those exact words, with that exact emphasis. No citation, no evidence to back it up, just asserted as present-day fact. Vendors and people who work for them have made clear that they don't want attestation in mass-market consumer implementations. The implementations themselves lack the support. The entire argument boils down to "well, who are you going to believe, me or your lying eyes?" I am believing the evidence of my eyes, and not the at-best-unsupported claims of people on the internet trying to whip up fear and outrage for clout.
The public communication isn't even necessarily the truth in many cases.
This implicitly asserts without evidence that Mondello and others have been lying. You don't get to do that.
I do not believe that the goal of Apple is to destroy freedom and "general-purpose computing". I believe the goal of Apple is to make money.
Very true. It just so happens that vendor lock-in is a pretty effective way to make money, at the very least in the short term.
I wouldn't bet that destroying freedom and general purpose computing can't be profitable. I'll fight to try and make sure it is not, but I can't help remember who the big corporations chose at the dawn of World War II. And of course, some right now are visibly siding with the far right, though few are as cartoonishly villainous as Peter Thiel and Palantir.
It just so happens that vendor lock-in is a pretty effective way to make money, at the very least in the short term.
If that's what they're aiming for, then all the interoperability and import/export stuff they've helped to standardize and then built into their implementation sure is a weird way of going about it.
And if Google was out to be benevolent, the way that they've been closing off the Android source, just by chance happening to make life difficult for Graphene and others... well, it must be a mistake, and I'm sure they won't do anything else like it ever again. If Facebook was out to be benevolent, the way they've been tracking users and correlating them, even going as far as bypassing Apple's app store to get users to install a tracking VPN, well, that's another minor oopsie, and I'm sure they've learned their lessons after it made them a bunch of money.
Megacorporations are large, and different teams within the company have different goals. Sometimes they align with users, sometimes they don't. Sometimes company politics switches who gets to make decisions about things, or sometimes an opportunity for profit too juicy to avoid squeezing shows up.
This is why technology needs to be designed with care, so that if the people in charge change, there's no easy switch available to pull. Building technologies based purely on trusting the people in charge is as naive as building a webserver without security measures, and hoping that attackers leave it unexploited out of the goodness of their hearts.
They did some things here and there, but Apple is absolutely not the company to show off as working on interpretability and import/export. You remember that promise of iMessage being an open system? Right now even if you reverse engineer it, you can't use it with non-Apple devices, because of... effectively hardware attestation.
Michael Tsai is saying: "It sounds like Apple is working on it". Those exact words, with that exact emphasis. No citation, no evidence to back it up
This is below exactly the quote you ask for, listing problems of attestation and:
We’re working hard with W3C and FIDO to solve these problems.
(The source seems to have been edited since then)
This implicitly asserts without evidence that Mondello and others have been lying. You don't get to do that.
He doesn't have to lie. Corporations have lots of divisions, sometimes with competing goals, sometimes just not aware of each other. What one person says may be the opposite of what another person is working on right now.
This doesn't read like a hit piece to me?
I am concerned about passkeys. Forgive me for not having an enormous amount of faith that big tech companies will not decide to do evil things in the future with the tools they have available to them. And to be honest reading the rebuttals from passkey advocates to the "Passkeys are a trap" post do not allay my fears at all, because all the arguments I've seen boil down to "trust us, this will never happen". It just comes across as naive given the direction that everything seems to going in.
The entire history of passkeys is one of the implementers fighting to keep things open and to build ever-increasing interoperability and import/export between their implementations, which is an extremely difficult thing to do with what is, literally, cryptographic key material.
The vendors have consistently refused to implement the attestation features for mass-market consumer devices.
Key figures at the vendors, who represent them in the FIDO Alliance, have used phrases like "over my dead body" to describe their opposition to mass-market imposition of attestation.
But still a bunch of people decide their vibes are that the vendors, especially Apple, are secretly doing it anyway. And... no. You don't get to do that and be engaged with in good faith. You don't get to say that fearful ignorance is as good as, or even more accurate than, informed expertise.
And you don't get to just say "sounds like Apple is working on it" without any evidence to support the claim, as Michael Tsai appears to have done in this post. You just don't. If you genuinely have concerns about passkeys you should be trying to make the strongest possible evidence-based argument you can, not sowing literal FUD.
The entire history of passkeys is one of the implementers fighting to keep things open and to build ever-increasing interoperability and import/export between their implementations
And botched it at a critical moment by using the same name for the unattested and remotely attested kind. Hopefully the mistake is neither fatal nor irreversible. But as long as both kinds bear the same name in people's head, they are liable to unwittingly switch to the "evil" kind somewhere down the line.
If we had two different names, it would me much harder to bait & switch, and the "good" kind of passkey would be much less likely to turn heel. It would at the very least assuage fears and spur adoption. I mean, I'd take public key credentials over passwords any day. Not just for fishing, I'm sick of password databases leaks already.
"sounds like Apple is working on it"
This is in reference to the Apple forum thread linked in the post where an Apple engineer says (emphasis mine):
Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind. [...] We're working hard with W3C and FIDO to solve these problems.
So yes, from that link it does sound like Apple are possibly working on implementing attestation. If they are doing this, I don't think it's with the intent to harm computing freedom/FOSS, and it doesn't sound like Tsai believes that either ("I believe this is not the goal of Mondello and some of the others working on this, but so far I’ve not been convinced that they will be able to control it"). I have no doubt that Ricky Montello and everyone else are sincerely trying to do good by getting passkeys out there as a replacement for passwords. So I reject this framing from passkey advocates of these concerns as a "conspiracy". The very problem is that no conspiracy is required, no mal intent is required for this to all end in tears in the future. We shouldn't even be in a position where this is a possibility, however remote you might think it is.
So yes, from that link it does sound like Apple are possibly working on implementing attestation.
This is why I really really hate the way people have latched onto the term "attestation" as a bogeyman.
An "attestation" is simply a piece of cryptographically-signed data. A PGP-signed email is an "attestation", for example, but that's not the kind of "attestation" people fearmonger about, so if I said that the GnuPG project is working on bringing "attestation" to the masses, I'd be technically correct but also misleading, because people will hear the word and think of something different.
Anyway, that's a four-year-old forum thread where someone was asking how to enforce a policy of using Touch ID to unlock passkeys. Which, if the enforcement is done by having the device send a cryptographically-signed data bundle about how the user unlocked the passkey, is a form of "attestation", yes, but like the example of signed email is also a different type of "attestation" than the one people fearmonger about.
And the Apple response was to say that, plainly: that's why the reply says the "attestation" in WebAuthn is not designed for this kind of policy. And the "working hard...to solve" comment is not saying "we, Apple, are working hard to force remote system-integrity attestation onto mass-market consumer devices", it's saying that Apple is aware they have corporate customers who want to be able to say during an audit that they require all employees to use biometrics to unlock stuff, as a mitigation for device theft, and that Apple is working on solving that.
We shouldn't even be in a position where this is a possibility, however remote you might think it is.
I've said before and will likely have to say again that this is the same basic reasoning the MPAA used to try to outlaw the VCR. The fact that it could be used for film piracy, they said, meant the technology was simply too dangerous to be allowed to exist at all. I don't think this is a line of argument you really want to join yourself to.
I think corporations should not have power to do things people don’t like and people should have power to do things corporations don’t like.
It’s not symmetric
Notice how so many things in the piece are linked and attributed, but then suddenly and mysteriously no evidence or citation whatsoever is provided for the author's comment
Missing the citation doesn't mean that nothing was provided. Maybe you didn't find the citation compelling or interpreted "working hard to solve" differently, but it does require a charitable interpretation of Big Tech's motives and history that not everyone holds. I'm not saying you are wrong, but accusations of bad faith need stronger evidence.
but it does require a charitable interpretation of Big Tech's motives and history that not everyone holds
No, getting from that forum thread to an assertion that Apple is working on rolling out universal forced vendor-locked-in remote attestation to mass-market consumer passkeys implementations requires deliberately deeply uncharitable interpretation that ignores the context of the thread itself, and also requires literally closing one's eyes, sticking one's fingers in one's ears, and ignoring the mountain of evidence pointing in the other direction.
I do not owe an assumption of good faith to any person who does that.
It's like the people who still try to cite that one GitHub issue with the KeepassXC maintainers as proof that the FIDO alliance hates interoperability and wants to force vendor lock-in, when the actual objection raised was to KeepassXC's plan of implementing export/import via plain text unencrypted dumps of private keys, and the person raising the issue was just asking them to either join in the more secure standard spec being developed for interop, or at least at bare minimum to protect exported keys in some fashion.
What you say sounds possible and you are welcome to hold those opinions. I will say that the ferocity and defensiveness with which they are presented does little to sway people to your cause, nor does it address the well-earned faithless reputation of the FIDO alliance members.
nor does it address the well-earned faithless reputation of the FIDO alliance members.
If the Big Passkey™ vendors actually wanted to impose attestation and vendor lock-in for mass-market consumer uses of passkeys, they already could have done it, easily. And yet they haven't. And if you believe they're just slow-rolling their heel turn on this, why on earth have they spent so much time and effort and money on building out interoperability and import/export capabilities?
The evidence we have is that the big passkey implementers stood up for users and held the line against demands from certain industries to force attestation into the consumer implementations, and that as a result the consumer implementations do not have attestation and vendor lock-in. And in return, people like you just assert, without presenting a shred of evidence, that they have a "well-earned faithless reputation".
If I seem to be deploying "ferocity and defensiveness", it's because of things like that.
Big Tech in general has an extremely well earned bad reputation, and so I get why it’s a pretty natural suspicion for that anything that could in theory increase their control. Especially when all of a sudden every site was constantly pestering you to use it.
And I’m glad there’s export now but launching without that set the tone very badly that this was a tool of vendor lock-in
Would someone explain to me how the trap is to be sprung, if passkeys become the dominant form of authentication?
Passkeys could have been so cool if they just were PKI that only works with one origin but they added a bunch of greedy other stuff that makes it extremely difficult to use for any situation other than one user per account on a device they own.
I don’t see this ever really changing sadly.
And the default password managers built into the OS 100% are a trap and my preferred 3rd party one (Mozilla) doesn’t support passkeys yet.
My new take as of recently is passkeys are okay as long as there’s still an easy email-based magic link forgot password option as well, but even with that the vibes are off.
makes it extremely difficult to use for any situation other than one user per account on a device they own.
one user per account: Any serious website should allow to create more than one passkey per account. Maybe you faced an implementation issue on a particular website?
on a device they own: Do you really trust devices you don’t own, like computers in an Internet café? Not me. This is basically the point of passkeys: getting rid of phishing and preventing insecure practices like using someone else’s device. However, if you want to share a device with someone you trust, you can register many passkeys for different accounts on the same device.
And the default password managers built into the OS 100% are a trap
Depends on the OS, but at least macOS/iOS works really well with passkeys right out of the box, and I’m sure Android is as good. Windows is fine if you enable Windows Hello. I don’t know regarding Linux.
But I totally agree that regular websites MUST provide an extra way to login without a passkey, typically with an OTP or magic link sent by email.
If passkeys are the Only form of Auth, how would I login on the other device to add the passkey there? My understanding is that there’s a complex flow involving Bluetooth and QR codes for this use case that only sometimes work and I really do not want to have to use.
If it’s just a convenience option and there’s email magic links or w/e that’s fine, but then I don’t get how it’s unphisable or what the point of all the extra hoohah is.
Any serious website should allow to create more than one passkey per account.
A good implementation is still extremely rare in my experience. I think Australian gov services still support only one for example. (Or they used to) It's mostly the tech companies that go into details like that.
Wow, you're telling me you do not have ultimate control over an account you create with a service you don't run, and the people running the service can force you use certain software to access their service? People need to know their freedom is in danger!
This is giving them new powers to validate what software you’re running via Remote Attestation that they didn’t have before, and (if you use the default, OS reccomended option) new powers to the OS to lock you out of third parties.
It also makes sharing passwords like Netflix or logging onto friends computers either much more of a hassle or impossible.
They also typically enforce strong passwords. A credential is not yours, it is a contract that you define with another party, and they can stipulate requirements.