Comment by dwaite | Hacker News Reader

Comment by dwaite | Hacker News Reader

Parent Full thread

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.

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.

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.

Reply on news.ycombinator.com