I believe the primary point is that WebAuthn is being pushed to use a "passkey" model where each site creates a credential that consumes storage. Displayable site and user account names, a user record handle, and the private key all take up storage, along with a few other items.

A mobile phone could store 10 thousand passkeys without breaking a sweat. Modern hardware keys might only be able to store 25 total in available flash.

The reason for wanting this storage is discoverability - the ability to hit say GitHub.com's new passkey support on the login page, and log in without having to even type in an account name. The browser provides a password manager-like experience. Just like passwords in a password manager, the passkey locally becomes a record of an account on a site.

However, WebAuthn also has quite a few other, non-passkey modes. Non-discoverable credentials expect you to provide a list of handles for a particular user account, which were provided by the keys as part of registration. Only credentials which match a handle are given as options during authentication. For hardware security keys, they leverage this to actually store the record needed for the future cryptography in the handle itself - this mode doesn't take up flash storage.

So the user would type their username, some API returns a list of handles, and this could be used against a security key to authenticate - without no storage limitations.

The problem with this argument IMHO is that a lot of sites take a policy of not revealing if an account exists or not. We've seen recovery processes that say "if this account exists, you should receive an email shortly". A login process that provides an API to detect if a username or email address has an associated account and how many credentials have been recorded against it may simply not be acceptable to the site.

It seems more likely that we eventually have security keys with 10x the available storage, rather than sites adopting this process widely enough to make an impact against the current hardware limits.

> The problem with this argument IMHO is that a lot of sites take a policy of not revealing if an account exists or not.

They don't, really. Because they have to prevent me from registering an account with the same identifier (username/email) as someone else, thus revealing whether an account exists or not. So the fact that the password recovery page doesn't reveal it makes no difference for someone who wants to know.

Some sites can do this by going as far as to say they've sent the activation email, then instead sending an email saying that there seems to be a registration attempt against their existing account.

How useful this sort of hiding is in practice is somewhat debatable. Github, forums, marketplaces and social networks all tend to have profile pages. I'm more likely to promote these as part of my public-facing persona as well.

The problem in this context I believe - if the largest sites on the internet think they need to protect information about valid accounts, most people will have passkey "slots" on a limited-storage key fob taken up by those sites.

The discoverability argument is somewhat weak because your browser already stores and probably prefills the username.

About not revealing whether an account exists: A site could always reveal a set number of potentially fake handles. So say a user has two handles registered, and the set number is ten. If the account exists, the two real handles will be in the list, alongside eight fake ones. If the account doesn't exist, all ten handles will be fake, but it's impossible to tell which case you're observing unless you have the key matching one of those handles.

Fake handles are possible, but nobody has attempted it yet that I have heard of.

There is no standard for credential handles (unlike what the article implied), so through heuristics you may be able to get some knowledge of which authenticator created them - and might be able to detect fake ones. You might want to pad both real and faked account lists to have the same number of returned values. These fake handle lists would also need to have some sort of heuristic to them - real accounts can change slowly over time, while fake accounts would be simpler to either always look static, or to regenerate on every call.

The system optionally saving a username is a nice convenience but doesn't really solve any deployment or security problems. Sites would be unable to rely upon that, and it doesn't help with information leakage.

You can save credential information in the client outside a security key and use that to 'upgrade' to discoverability - but you then have that security key only function on certain websites when using that client. You brought your own security enclave but are still platform-bound.

How wouldn’t one of them be the one you’re looking for? I.e. still revealing an account’s existence

I'll try to explain their argument under the assumption handles were convincingly fake, e.g. there wasn't a heuristic to tell real and fake handles apart.

The underlying protocol (U2F or CTAP) will send all received handles to the separate hardware authenticator. Some of these may be real, some may be fake. Some may have been created by other keys.

There is a process to convert correct handles to a correct private key inside the hardware. This _should_ have some sort of integrity to prevent taking incorrect handles and creating garbage private keys as well - those will fail, but the user experience will be sub-par and there are always cryptographic concerns about processing attacker-chosen data.

So when I make the gesture to authenticate, the valid private key which came from a correct handle is used to sign a response message to the authentication request. All the fake handles and those created by other keys would be ignored.

So if the handles are convincingly fake, the web site would be the only one which would know which were real or fake (so that it can still offer proper user self-service management). An individual piece of hardware would know which were real handles that it created. An attacker wouldn't know if they were all fake.

It's a poorly argued point, agree. Essentially the author is arguing that the ability in the WebAuthN protocol for Relying Parties to be able to specify `rk=required` is considered harmful because it excludes tons of TPM hardware from being able to work as a Passkey wallet/db. I think most people in the comments probably agree. That doesn't excuse all the confusion the author creates by essentially bike-shedding the definition of passkey for half the essay.

I think the upshot is this:

The hype around passkeys is high enough that basically all authentication layers are requiring passkeys when they're available. This is a problem because passkeys must be stored in the client-side authenticator (password manager, hardware token, whatever), some of which have very limited capacity for storing them.

This is compounded by two problems: (1) Extant standards for storing these keys on hardware tokens don't allow deleting them individually, though this is changing in the newest standard; (2) Many current hardware tokens claim to have huge capacities, but this is based on a different challenge-response mechanism than passkeys. As a result, users will be pressured into using passkeys often, run out of precious passkey space despite thinking they have plenty, and then be forced to forego the benefits moving forward or reset and lose their keys.

Is that more or less accurate?

The article assumes quite a bit of knowledge of FIDO2 and your confusion is understandable.

> How/why? What's the connection to passkeys or HSMs?

Passkeys are implemented on top of FIDO2 and specifically utilise the "resident key" functionality of the FIDO2 spec (according to the article; I don't personally understand passkeys). FIDO2 hardware authenticators are not HSMs exactly, though they are similar and some devices (like Yubikeys) are both HSMs and FIDO2 authenticators.

> Yeah okay... does this imply that all resident keys are discoverable keys? Or that all discoverable keys are resident keys? Or both?

In FIDO2 "resident key" and "discoverable key" are synonymous. "Resident key" is the term used in the spec, however "discoverable key" is commonly used. One of many such cases of FIDO creating confusing terminology.

> No. Does "keys" here mean passkeys? Or keys stored on HSMs? Or both? Or something else entirely?

Neither, it refers to FIDO2 hardware authenticators (e.g. Yubikeys) which are commonly referred to as "security keys".

> Okay so an HSM can apply to an unlimited number of accounts because it can store... some kind of key wrapped in another key (of the same type? different type?)

A FIDO2 hardware authenticator (which is not a HSM per se) can be registered with unlimited accounts because it is effectively stateless; it doesn't store anything (assuming that you are NOT using resident keys, which must be stored).

When the authenticator is registered with an account, it generates a key pair on the device (e.g. an EdDSA key pair). Instead of storing the key pair, it encrypts the private key with the onboard master key (e.g. an AES256 key). It then sends the plain text public key and the encrypted private key to the "relaying party" (e.g. google.com) who stores it. When authentication is attempted, the encrypted private key (i.e. the "wrapped" key) is sent to the authenticator where is decrypted onboard and then used to produce a digital signature.

Note: The FIDO2 does not actually specify how to implement non-resident keys - wrapped keys are just one way of doing it. FIDO2 only requires that the private key must be securely derivable from the credential ID (where the credential ID is actually arbitrary data which may or may not be a wrapped key).