> Being able to zero-effort cleartext a passkey strips it of the HSM-lite properties that make it safer than passwords.
You might have an argument if we were talking about device-bound keys. But the second we start talking about roaming keys, this just becomes a bad excuse. iCloud accounts can be phished, Google accounts can be phished. Roaming keys are vulnerable to phishing. The ability to export a key (encrypted or not) does not change that.
Device-level attestation and platform control over keys is out-of-scope and inappropriate for a credential that is fundamentally designed to live on multiple devices. We aren't talking about Yubikeys or device-bound keys, we're talking about roaming keys that are designed to get synchronized to the cloud and moved between devices at the direction of the user. Necessarily, there is going to be some level of phishing risk. We've accepted that because device-bound keys are unacceptable for most average users even if they're more secure.
Notably, this does not mean that passkeys are useless or that they are not phishing resistant. There are a large number of security benefits from passkeys even though they are not completely phishing proof. Those benefits do not go away if attestation is not supported for roaming keys, nor do they go away if users are able to decrypt their own keys. And given that companies like Apple led on zeroing out attestation requests for roaming keys, there clearly is not consensus in the FIDO Alliance about whether attestation is desirable or necessary for roaming keys.
Passkeys in a world where users can inspect and access their own keys are still a meaningful security improvement over passwords. And importantly, the lack of attestation makes it more feasible that they will actually be used. The goal is not to make something perfectly secure, the goal is to replace passwords with something better. I am continually surprised to see how little people understand about the myriads of use-cases that passkeys will need to support if they are going to actually replace passwords, and how little they seem to care about the ability of an attestation-encumbered system to handle those niche cases.
I've been in this space for a while. First, advocates told me that roaming keys were never going to happen because the whole point was for keys to be device-bound. Then it turned out, well, that's a dealbreaker, so we can compromise on that. Then I was told that sharing passkeys was never going to happen because it would destroy the security benefits. Well... okay, now we support sharing. Then I was told that migration was out-of-scope and the FIDO Alliance was not going to get involved. Now the FIDO Alliance is involved. Then I was told that export was fundamentally insecure, and any migration between providers would need to happen via a secure channel online or without ever putting the passkey on disk. And now I'm told that, okay, we can put the passkey on disk, but the problem is that it's zero-effort to get a cleartext. And at every step of that process, I'm told that these are non-negotiable security properties of WebAuthn.
Well, after a while these all start to feel less like security principles and more like excuses for why export isn't happening. It's weird how these security principles only get brought up in regards to user freedom, and not in regards to Apple supporting passkey sharing over Airdrop. I'm sorry, that doesn't open up phishing risks?
Tim suggests in this issue encrypting the passkey with some kind of additional key on export. How does that mean that HSM properties are preserved? The horse is out the barn, we are not doing HSM security on roaming passkeys, we are just pretending to. HSM gets brought up as this important feature but passkeys are already ignoring it. So let us export the keys; enough with this bullcrap double-standard about what does and doesn't count as a phishing risk.
----
> The sky is falling, yet no one discusses how freedom and attestation might coexist, and so the majority use case (end users) is winning.
Sure, I'll start the ball on that conversation. There's a straightforward indication now that attestation and certification can be used to punish and block spec deviations (https://github.com/keepassxreboot/keepassxc/issues/10406#iss...). This comment could not possibly be more clear, FIDO Alliance is looking for ways to force providers to implement in specific ways.
And that's interesting because in the past I have been told that interoperability and universal import/export cannot be required by the spec because the FIDO alliance has no way to force providers to interoperate, and because interoperability is out-of-scope. The only thing we can do (I'm told) is hope that companies support export/import out of the goodness of their hearts.
Well, now we know that those arguments are wrong. FIDO members are willing to get involved in discussions about how projects do or don't handle migration so this is very clearly "in-scope", and FIDO members are willing to get forcefully involved, and are actively working on mechanisms to require independent projects that are not members of the FIDO alliance to seek certification. FIDO is going to have a level of control over how providers act.
So if we must have attestation, is anyone involved in the spec process for WebAuthn willing to publicly commit right now that export/import for roaming keys will be a required part of the spec and that failure to implement export/import will result in blocking certification? Why is it that attestation is being used to shut down user agency, but for corporations we have to just trust that they'll do the right thing?
We've apparently got this amazing tool for forcing compliance. That implies to me that user freedom can be part of the spec and those compliance tools can be used to safeguard it. If we're talking about using attestation to enhance user freedom, then using attestation to require universal export/import controls with every single certified provider would be a pretty big selling point for attestation, and would go a long ways towards avoiding the mistakes that were made with 2FA, where many apps straight up never provided a way to export keys. I wouldn't be thrilled with it, attestation would still be dangerous, but at least it could be used to ensure that the ecosystem guarantees user rights as well as restricts them.
But I'm not holding my breath that the FIDO Alliance is going to require that kind of thing.
It is not for lack of conversation that attestation is primarily used today to curb user freedom and agency. It is that the technology is naturally prone to abuse if it isn't coupled with adequate safeguards. Early on during TPP debates, proposals were made for ways to make TPPs that coexisted with user freedoms and enhanced user freedoms. It is not that Linux communities aren't involved, it's that we correctly recognize at this point that practically every single real-world implementation of attestation has been used to shut down user freedom because it is fundamentally prone to abuse. So what safeguards is FIDO going to put in place? How is FIDO going to use attestation this time to actually help user freedom?
Because I can think of ways: mandate interoperability, require implementations to be open and documented, require cross-platform support for most providers, require fall-back methods of authentication for users who do not own hardware that can handle attestation requests, publicly commit to making attestation available to De-Googled phones and to "authorized" 3rd-party ROMs.
While we're at it, require clients to support multiple keys per-domain which by extension would effectively force domains to accept multiple keys. Today, there are domains that only allow registering one passkey, which is wildly irresponsible given that registering multiple keys is the only way right now to simulate portability. If we're going to use attestation to threaten non-compliant implementations, then at the very least we could also use attestation to threaten implementations that deny user freedom and agency.
Will FIDO commit to any of that? Or do I have to simultaneously watch Open Source provider implementations get threatened by attestation while also listening to advocates tell me that there's nothing the FIDO alliance can do to require an Open ecosystem with universal data-portability?