Pretty funny to reference anti-open-source reddit in a privacy community

It may make it somewhat harder, but I wouldn’t say it makes bots impossible (eg. device farms).

But I agree botting has nothing to do with what we are talking about.

We are talking about “capturing” the user and I’m saying the protocol has built-in a method for services to require the users to use only the authentication methods the service allows.

The attestation certificate includes metadata securely identifying the exact maker, model, and capabilities of the local authenticator you used, with the purpose of allowing services to verify if they trust the authenticator.

So if you use your own no-name open source fork of a particular authenticator and don’t even register it with the FIDO Alliance Metadata Service then services requiring attestation would reject your keys (unless they explicitly make the exception for your particular AAGUID… but at that point why ask for attestation in the first place?).

The point is that not all protocols are created equal. So “we shouldn’t have created HTTP” depends on what HTTP is specifying.

If a protocol makes it easier for big players to abuse the system, then it’s a worse protocol in that respect.

The point being made against passkeys is that, in some respects, it’s worse because of the inclusion of attestation as part of the standard.

Who has used as argument that passkeys are phishable?

The argument is that passkeys include “attestation” as part of the official standard, which is a method explicitly intended for services to be able to securely identify what local authenticator you used with the explicit purpose of allowing the service to reject access if it’s not considered “safe”. Can you say that about TOTP?

The problem is not the general idea of passkeys… there are actually good things in the standard. The criticism was that there’s also a part in the standard that seems perfectly designed for companies to use them in anti-consumer practices.

Imagine if HTTP explicitly documented as part of the standard that the “User-Agent” header, when provided, must include a tamper-proof cryptographic signature that allows to securely identify which browser version the user has (with a consortium maintaining a list of registered browsers) so that websites can reject access if you are not using a browser they trust or they don’t like that your browser is too old…

Considering how much abuse there has been with the User-Agent header… I can’t imagine it being a good idea to include such a thing in the standard.

If on creation HTTP had included things like that, then I think Gopher and other competitors at the time might not have been a bad option, honestly.

A good start would be to not bundle into the protocol a method explicitly intended for services to be able to securely identify what local software (or hardware) you used with the explicit purpose of allowing the service to be able to reject access if that client software (or hardware) is not allowlisted.

Passkeys is a great idea. But the “Attestation” part of the protocol …not so much.

The point is that attestation allows for services to restrict where do you put it on.

The attestation certificate includes metadata securely identifying the exact maker, model, and capabilities of the local authenticator you used, with the purpose of allowing services to verify if they trust the authenticator.

So if you use your own no-name open source fork of a particular authenticator and don’t even register it with the FIDO Alliance Metadata Service then services requiring attestation would reject your keys. Unless they explicitly make the exception for your particular AAGUID (at which point… why ask for attestation in the first place?)

The issue is not with passkeys themselves, but the attestation feature specifically, which is part of the standard.

There are actually 3 categories (though the idea of 2FA is picking 2 out of 3):

• Something you know (passwords, PINs, security questions…)
• Something you have (hardware keys, TOTP, smartcards, SMS/push-notification…)
• Something you are (fingerprints, facial recognition, iris scans…)

But passkeys collapse 2 of those into one by having the passkey algorithm include (as a step of the key derivation) a passcode or some biometric data… that’s why most passkey systems require some form of verification. Though it’s up to your authenticator which method is used.

they can’t force the passkey in to protected storage, as long as there is a browser like firefox in between you and them.

You also need to not use Windows Hello, or Apple Touch ID / Face ID (which actually is the default in Windows & Apple, even if you are using Firefox). Otherwise the browser will relay the request through them and provide the attestation.

The problem is when the mainstream people do use those methods because it’s the default, they don’t know, or it’s simply more convenient since it’s bundled in their proprietary OS that they (stupidly) trust.

If having your own non-attested custom method of providing your passkeys becomes something niche amongst the users of passkeys, then I would not be surprised if many places flip the switch and start requiring attested methods.

Of course one can always switch to more consumer-friendly alternatives even if they are more niche, but as long as they remain niche it won’t stop the big services from pushing for anti-consumer practices.