Passkeys.io – A Passkey Authentication Demo

As a user registering an authenticator with a typical site, the authenticator creates a public/private key pair and returns the public portion. Using it later tells the site it is the same authenticator as last time, without options to release much more information than the batch of authenticators it was manufactured in.

So if you register _again_, perhaps as a different user, all the site would see is that they have two users with 'Early 2021' Yubikeys. Even this level of identification still requires the site to request attestations, which the user has the option to reject.

My demo sites may have pages of users from dummy accounts, if I don't periodically clean them up. The site has no way (official or heuristics-based) to know these are all from the same person or same piece of hardware. Different sites also wouldn't see that you were the same.

The authentication and registration flows also require some act of user consent (such as tapping a key) to release _any_ information at all - you can't find out ahead of time that the user has a credential registered. This also makes sense when you think about ones which communicate transiently - my phone might not know that I authenticate with NFC until I tap that security key against the reader.

What's allowed behind the scenes can muddy this up a bit, so I'll list that out too:

1. Sites can provide a list of registered credentials to try to keep you from registering the same authenticator twice under a single account. This works as a filter during the consent process, but the browser doesn't know if say these were across multiple accounts. If a small site provided the entire list it would block you from registering the same security key against multiple accounts - but the site wouldn't know it was successful in doing so.

2. In addition to the classic second-factor mode (where the site provides all the credentials it would honor for authentication) there is a _discoverable_ mode, used by passkeys, where the site simply says "what you got" to use as a first factor. These take up storage. So some keys may have limited storage and not want to support multiple passkeys for a single website at all.

3. There is a feature called Enterprise Attestation where your system policy (or policy on a pre-provisioned security key) may report its serial number to white-listed sites. I consider this more a problem with privacy impacts with managed devices in general, and many platforms don't support that feature at all. I believe pre-provisioned security keys must wipe out any such policy on factory reset, but that would likely then limit your ability to use that key to access corporate resources.

Authenticators and clients can certainly abuse your trust and break your privacy assumptions. The platforms are generally acting as clients and limiting access for other software to act as clients to prevent correlation attacks and phishing attacks. They use API access to limit what a website or native app can request.

These clients may also block-list authenticator features or whole authenticators which do not meet their published requirements.

https://www.theverge.com/2022/8/31/23329373/dashlane-passkey...

My guess is that a demo app was pummeled a bit and fell behind on the email verification queue.

That aside, only the part where you register a new credential (e.g. the browser/OS modal dialog) in that registration process is using passkeys.

I personally hope there is more of an 'officially supported' integration in the future with the various browsers and platforms. "Passkey managers" need to be able to integrate with native applications just as well as they do with web apps inside browsers. The fall-back of 'I'll just copy and paste the password over' won't work if the credential isn't text.