How can the "cartel" "blacklist" anyone? The only thing the FIDO alliance can do is not include a vendor's attestation key as trusted in their vendor database, and software solutions aren't on that list to begin with.
> The fundamental flaw is that enrolling an authenticator requires it to be present [...]
Yes, but that doesn't mean you can't backup the full authenticator state.
Here's a toy WebAuthN implementation that is backed by a passphrase that you remember or write on a piece of paper which works on many websites supporting passkeys and not enforcing attestation (which is the vast majority, since Apple, Google, 1Password, and Bitwarden all don't support attestation for synchronized credentials a.k.a. passkeys): https://github.com/lxgr/brainchain
> Making it hard/impractical to maintain a reliable backup yourself sure makes those proprietary sync-based services attractive
It's also completely open source and can be backed up :) (But again, it's a toy demo – don't use it for anything sensitive!)
All they have to do is publish a "best practices" statement or some RP certification program mandating attestation to be used (and some PR around how only "certified" RPs are secure) and job done. The only reason they didn't do that yet is that Apple is refusing to play ball and support attestation (but this may change).
The threat was clearly there in the original Github issue, and it's just a temporary inconvenience they can't currently follow through on it.
> Yes, but that doesn't mean you can't backup the full authenticator state.
Having the secondary authenticator present in the same vicinity as the primary one exposes it to risks. Having to dump authenticator state at regular intervals now means your backup authenticator must be reachable for writing online, so it can't be a simple "cold storage" backup like a Yubikey in a safe anymore. This also opens up security concerns since you're now dumping and syncing private keys left and right over a network and you lose the peace of mind of using an HSM-backed non-exportable private key where the HSM being unplugged guarantees nobody is currently using your keys.
Seems like a shit ton of complexity and effort to work around a problem OpenSSH elegantly solved 30 years ago.
> Here's a toy WebAuthN implementation
Thanks, I will check it out and read up on it. I'd be genuinely happy to move to WebAuthn if I could build my own hardware authenticators that allow the backup one to remain fully offline in a safe, and not have private keys flying around (if I'm doing that, it's not much of an improvement over syncing passwords - except those I can at least type or tell over the phone in an emergency when I need someone else to act on my behalf).
Edit: so it seems like I am mostly right? Only discoverable credentials count as "passkeys", and those generate per-site private keys, meaning offline, cold-storage backups are impossible. I guess I'm sticking to my password manager then since passkeys would provide no improvement in this case.
> The fundamental flaw is that enrolling an authenticator requires it to be present [...]
Yes, but that doesn't mean you can't backup the full authenticator state.
Here's a toy WebAuthN implementation that is backed by a passphrase that you remember or write on a piece of paper which works on many websites supporting passkeys and not enforcing attestation (which is the vast majority, since Apple, Google, 1Password, and Bitwarden all don't support attestation for synchronized credentials a.k.a. passkeys): https://github.com/lxgr/brainchain
> Making it hard/impractical to maintain a reliable backup yourself sure makes those proprietary sync-based services attractive
It's also completely open source and can be backed up :) (But again, it's a toy demo – don't use it for anything sensitive!)