FIDO Alliance

Yes, fido2 defeats allot of the attack vectors for phishing attacks and is great.

While physical devices probably will mostly be used for enterprises and us nerds, “platform Authenticators (e.g passkeys) offer much of the same security without the physical device

Attestation is an option in the FIDO ecosystem, and it is up to each website whether or not attestation is needed. Attestation is often required in enterprise settings. While consumer adoption of WebAuthn is incredibly low, the introduction of passkeys and multi-device credentials looks poised to change that.

For consumer scenarios, attestation is often not a requirement. In that case, FIDO offers the "none" and "self" attestation modes. None conveys no attestation. Self attestation involves a per-website key pair. Either of these modes are privacy and DIY friendly.

Please note that verifying Metadata is optional for a RP (site owner) and very few sites need it. Without metadata information the privacy is improved.

Disclosure: We built an open source library and an API that makes it easy to add WebAuthn/Fido to your existing web app. It’s available at for those who want to take a look. https://www.passwordless.dev/

There is also a more configurable demo page for the library where you can turn metadata on/off (the api is default off)

In Firefox you can, and I do, tell the browser to refuse Attestation. There's a prompt during the enrolment process.

There's no reason why you should provide Attestation for the Web generally. It could make sense (though I'd argue it does not) for some specialised applications but generally it's probably a waste of your time (collating the necessary data to make it work) and your users time (now some stuff they want doesn't work and needs explicit authorisation).

Most open source tools I've seen that implement FIDO use a shared Attestation cert[0].

[0]: https://github.com/github/SoftU2F/blob/master/SelfSignedCert...

> ... will likely mean you'll be generating that private key yourself, this makes you identifiable across registrations.

DIY/CLI apps have no reason to include a legitimate attestation - attestations are used to convey trust in the implementation, such as 'This is a Yubikey 5i'. The public key is usable to look up additional metadata, such as passing conformance and security implementation tests.

>Some sites (Cloudflare) may reject the use of attestation keys which are not found on the Fido Alliance Metadata Service. This precludes the use of any DIY solution.

The feature is meant for higher security environments (say workforce and government employee/contractor) to reject a home-grown implementation.

Cloudflare's (beta experiment) usage is a special case because they are using attestations to show that it is real hardware with a real financial cost. They are experimenting with using that as a replacement for captcha entering (while also experimenting with other technologies like privacypass to limit the number of times they ask for captchas).

The alternative to attestations in both of these use cases is that FIDO is not acceptable at all, not that a DIY implementation would become accepted.

They're just trying to replace the current system of password reset calls, SMS two factor, credential stuffing, password database breaches, and a general wild wild west feeling on the Internet.

Of course it'll take more than public key authentication itself. For example in a enterprise businesses employees aren't allowed to install software, and there are procedures (however bad) to vet individuals.

Or apple's iCloud (see their passkey thing also currently on the front page)

EDIT: Yes you don't need to use a syncing service. But it will be important for it to be portable between syncing services, as that is what most consumers will be using.

> This means keys need to be transported between devices

Pure keys are on tokens that support Bluetooth/NFC/USB to talk to whatever devices you want. One can use a built in key on a device with a security enclave which means using one device to auth addition of another, but you might do that with alerts to authorize, etc.

Anyone who doesn't have a powned problem is using something like TOTP auth codes which has all of the downside of Fido and none of the convenience.

Unlike username/password you can register as many FIDO devices as you like in each service so if you lose one (because Apple disabled your Apple ID or whatever) you can still login.

[Your account has been suspended due to user generated content not consistent with Metaverse(tm) community standards.]

My first thought was "Is FIDOnet still relevant after all these decades?" then remembered FIDO U2F

It's simple for users. No need to remember passwords anymore, no typing 6 digits numbers from your phone that you need to search in your house before tokens expire.

This comes with (some) additional complexity for implementing more complex auth flows for developers.

If you think that passwords are working "well enough" today you are clearly not educated on how most users (mis)use them. If you built a site and tried out the passwords people send to you on the logins for providers of the email addresses they send to you, there'd be a large fraction of people reusing their email account password for your service, allowing you to access their email.

The only real problem with passwords is that humans are extremely bad at those without an aid of a password manager (when they’re no longer words but turn into pre-shared tokens). There are more, of course, but not as important.

So people invented OpenID and OAuth and stuff, but all those things are fundamentally flawed because users were no longer a source of their “own” identifies. Their identities became provided by third parties - and this is notoriously bad.

WebAuthn (and FIDO stuff) is not centralized, on the contrary - users still own their credentials and are sources of their identities (though there are optional attestations). It doesn’t require cryptography knowledge to use it, but it does to implement it - thus the certification (though anyone can surely do it without certifying for anything).

I've had so many of my non-tech relatives get hacked. Folks who don't live/breath/shit tech just kind of suck at p/w management. This is a huge improvement for them.

BUT, I absolutely think we should continue to demand the right to interact with services on our own terms: Even accepting the compromise of "less security" (debatable if you know what you're doing).

I think the only way forward is a Free/Libre implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want. Even a fully-software one.

As long as it sticks with FIDO2 Authenticator L1, it doesn't require centralization of the auth information like levels L2 and L3 do. L1 is what you use if you want control. L2 and L3 are for companies who want tighter, centralized control. Like a FIDO key tied to your Okta account. Though I've yet to see the Levels discussed much nor have I seen any L1 software implementations used in the wild. Everyone seems focused on FIDO L2 and higher, presumably with a focus on getting enterprise adoption first as enterprises do want a central authority.

You don't need those either, perhaps https://github.com/herrjemand/awesome-webauthn is more to your liking than the website of a standards organization.

What's there to explain? We're presumably not teaching your parents to actually implement this for a web site (although I did it in a weekend once to learn) just to use it. Do your ageing parents still have car keys? House keys at least? The physical Security Keys are probably easiest to grok for older people, because of that familiarity.