Passkeys.io – A Passkey Authentication Demo
passkeys.io
passkeys.io
If I have a single hardware key/tpm/yubikey/iphone/etc - can you create multiple users on one site? And can they tell that you're the same user? Or are you now locked to just a single user for your phone/macbook/yubikey/whatnot?
Also if multiple services colluded (or integrated with say GA) - can they (or at least GA) all tell that you're using the same hardware key across services?
Unless I'm missing something this sounds like very bad news for user privacy
As for privacy, services can require additional info from your key (WebAuthn shows an additional confirmation button). This info includes the manufacturer and probably some other info (not sure about that). Otherwise it should be impossible to tell if a single key is used for multiple usernames.
Of course, other signals like origin IP or browser fingerprinting can be used to correlate identities.
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.
It works like this (WebAuthn non-resident keys):
1. YubiKey contains symmetric key.
2. When you register to WebAuthn service it generates random private key/public key, encrypts the private key with symmetric key, and sends this as token to server. Along with your username and newly generated public key.
3. When you login to WebAuthn service and type your username you get back the token. YubiKey then decrypts the token to get the private key, and answers to the challenge server gives in public key.
In other words, you don't need to store the public/private keys at all, all you need on the client side (YubiKey) the symmetric key. The private keys are stored on server you login.
For WebAuthn resident keys it needs to store info, more here:
https://developers.yubico.com/U2F/Protocol_details/Key_gener...
For the first part yes, you can re-register the key multiple times for multiple accounts on the same site, and generally speaking these are not very correlatable on the basis of the token itself, as long as you have gotten a non-dodgy token (ie, one with a unique attestation cert). There may be other ways to strongly correlate the users however, and then the token may give the final (hard) proof the site was looking for. As a trivial example, linked in does a simple correlation on src IP. If you create 2 fake LI accounts and visit from the same IP, after a ramp up time LI will ask each of them if you want to connect to the other. But in this case, LI already had the info necessary to associate the 2 accounts. The token itself isn't the tip of the spear here, that makes this possible.
Cross-site collusion is prevented by restrictions on the RP ID. So as long as the browser is functioning correctly sites cannot collude to use the token as a supercookie.
> Unless I'm missing something
Well the thing you're missing is that you're simply supposing these things. But these things are prevented by, and intentional in the design of U2F/WebAuthn.
And if you don't trust the browser, or want to protect against sophisticated correlation attacks, "just" use a different token when you want to go dark. I'm not sure why you have this underlying assumption that a person can only possess one token.
One caveat: I've no idea what you're referring to with "GA".
Probably means google analytics.
1) How can I share the fingerprint keys between chrome and safari?
2) How do I share keys between different types of devices? (mac, ios, android, windows)
3) What happens if my devices are gone?
4) What happens if I want to change my login (email to a new email for example)?
5) Is account recovery handled simply by a reset-email?
6) It seems a validation step of the email is missing?
2. Apple does this using Keychain (iCloud), but that's limited to Safari in iOS/iPadOS/macOS.
3. I assume would be treated as any other MFA option; if you lose your auth code generator with no backups, you're SOL. With Apple, you can setup what they call a contact recovery, which lets a trusted contact be a point of recovery for your account.
4. I don't believe this is an issue specific to Passkeys.
5. Account recovery isn't really necessary, unless you hit up against point 3, in which case it's about recovering your ability to use the passkey and not so much the account.
6. If emails are being treated as usernames, they absolutely should be validated.
Unless you want to switch from Safari to Chrome, I guess?
My working assumption is if you wanted to use a new browser, you'd have to attempt to log into the service with the new browser. When the Passkey flow prompts you with a QR code to scan, you'd have to use your iPhone/iPad to scan that QR code to allow entry. What happens after that, I have no clue.
Switching from one password/-key manager to another is going to be more of an issue.
But you should be able to add an additional passkey once logged in to an account, just like how you can have multiple hardware 2fa keys now. Then you could manually migrate accounts that way, which is painful, of course, but you wouldn’t be completely locked in.
If you're talking about TouchID then - keys aren't stored in a browser, they stored in whatever powers Touch ID (secure enclave?). So any browser that supports Webauthn will be able to reuse it.
> 2) How do I share keys between different types of devices? (mac, ios, android, windows)
Yes. I have multiple hardware keys that I use on: iPadOS, Android, Mac, Windows, Linux. Key exposes itself as HID, so it "just works"
> 3) What happens if my devices are gone?
Then you have to perform account recovery, just like when you forget your password
> 4) What happens if I want to change my login (email to a new email for example)?
Email isn't stored on the key. So changing email to a new email if entirely dependent on service you're logging in, just like in case of a password.
> 5) Is account recovery handled simply by a reset-email?
This is unrelated to passkeys and webauthn. This is a replacement for authentication, not account management, so yes, it's handled the same in a way that is entirely up to service how to handle it.
> 6) It seems a validation step of the email is missing?
I think at this point you can answer this question yourself?
1) How can I share the fingerprint keys between chrome and safari?
You don't need to. That's not how it works. Chrome and Safari and every device will have a different key for the same service (see video)
2) How do I share keys between different types of devices? (mac, ios, android, windows)
You don't. You authenticate and a new key is created on each device, possibly on each piece of software (Firefox, Chrome, Safari, App). To be more clear, when and if you decide to use a service from a new device or new browser you'll be asked if you want to login via passkey. If you have a passkey on another device you can (see video) use that to login from the other device (similar to how google asks viat the gmail app of you were trying to log into some other device or Apple asks across your device). After you authenticate you can then create a new passkey for this device/software you're using. This new passkey is separate from the previous passkey. You effectively have 2 passkeys now, one to login with one device/software, one to with a different device/sofware. (See video)
3) What happens if my devices are gone?
You follow whatever recovery procedures the service has.
4) What happens if I want to change my login (email to a new email for example)?
Unrelated. Your email is not shared with passkey. So login and set a new email
5) Is account recovery handled simply by a reset-email?
That's up to the site/service just like it is without passkey
6) It seems a validation step of the email is missing?
That's up to the service as well. They could require an email but that's unrelated to passkey
[0] https://bitwarden.com/help/setup-two-step-login-fido/
[1] https://community.bitwarden.com/t/unlock-bitwarden-with-2fa-...
https://blog.1password.com/1password-is-joining-the-fido-all...
https://www.theverge.com/2022/8/31/23329373/dashlane-passkey...
Alternatively, and likely a much better option longer term, they'll need operating system support that provides them with APIs to establish trust between authenticators and export passkeys wrapped with keys corresponding to trusted devices, not unlike how these OSs provide APIs for integrating password managers today. A growing number of password manager vendors have joined the FIDO alliance, hopefully to help move this along. Establishing trust between devices in a Sync Fabric is also something that needs careful consideration if not a standard, since it's a huge target for phishing.
In either of these cases Passkeys from different vendors aren't interoperable.
Safari on a Mac requires me to enable iCloud Keychain in order to use Passkeys and has no way around that requirement.
Mobile Safari presents me a QR code to be scanned by another iOS device o_O
Hope it will change though and I can sync my passkeys using 1password for example. I don't want and password manager and a separate passkey manager on top of that....
Email access is basically total access.
Unfortunately, passkeys.io as a demo falls back to a legacy "no passkey support" behavior for Firefox, without making it clear (as a demo site) that this is happening.
And regarding the privacy. You can deploy as many certificates/identities as you want on multiple accounts and sites. It's not possible to track them across sites or even across accounts, since there is no CA involved.
To make it worse, when I'm trying to sign in, it prompts me for my Yubikey PIN, and not Windows Hello PIN. Basically, multiple token support is badly messed up.
This is an issue we've run into a lot at $work where users will forget their FIDO2 pin cause its only used during registration, and never after that, and when they reset the pin it destroys all their previous known 2FA (which is expected).
This is a new requirement from Microsoft.
It's exactly the same for Windows Hello built-in authenticator, they require a PIN (or face, or whatever other means you have configured) for the computer itself. Same for iPhones, you need a PIN or password to unlock it. It's merely a matter of frequency (phones and laptops are unlocked daily, Yubikeys - depends on the individual), and if use of hardware tokens is prohibited (or even discouraged) from the very beginning they'll never have a chance and the world would go the path of least resistance once again.
I'm curious if resetting a PIN or password on Windows or macOS or iPhone OS would retain the Passkey identities. I suspect it would...
See, pins for yubikeys don't make much sense to me. If you have to enter a PIN and press the button on a token, that doesn't seem very different to entering a password and pressing the button a token which U2F has offered for years.
Pins make a lot of sense when you start using a yubikey as your primary form of authentication (instead of as a second factor). Note that there are other ways to perform 'user verification' besides a pin. For example, biometrics are specified in the FIDO2 spec, and implemented by yubikey in their Yubikey Bio product.
The reason they are referred to as PINs rather than passwords is that they are locally set and entered, without being shared with external network systems. Since they are being used to augment the physical security properties of the hardware device, the PIN can also be far simpler than a typical password - someone has to steal your hardware before they can contemplate forcing the PIN.
This additional user verification over the physical factor is used for two purposes:
1. The site can request user verification as part of accepting this system as a one-stop replacement for their current two-factor authentication systems.
2. Enumerating what credentials are on a key is often PIN-protected, so that someone who has temporary access to your security key (such as at a border checkpoint) can't inspect which sites you have logins against without your knowledge/consent.
This second one is the more annoying of the two - I might have the system request my PIN just so it can tell whether that particular security key is a viable source of credentials for a particular site.
This part of the overall design seems problematic to me. These “resident” keys are described as “passwordless”, but they’re really username-less. And an attacker who gets the security token can not only log in but they can also enumerate all credentials. Ouch!
ISTM a much better design would have been to put the credential list on the browser side. If I log into a website that I’ve used before from the same browser, the browser’s credential manager can remember my username (and optionally key handle) and the external token can do a normal authentication. No website state is stored on the token, and the experience is almost as good — the user only ever needs to enter their username once per browser.
Depends on the process for changing the PIN/password. The desktops may have an option to log in with the cloud account, which can have separate recovery processes.
If I lose my PIN to my iPhone though, pretty much my only option is a device reset. The difference with Passkeys is that they are bound to an iCloud account, not the hardware - so I get them back on device restore.
Some of the security key enterprise and government customers also don't necessarily want credential backup/restore. Handling the account recovery and key registration process in their environment has more quantifiable risk than having it as an external process.
Perhaps I'm naive, but how are passkeys "way more secure" than "all current 2-factor authentication methods"? Don't many security keys (e.g. Yubikey) also require that you are in possession of the physical yubikey? I'm using that as a 2-factor authentication method. Why is a passkey more secure?
Update: Ah, reading closer it seems that they mean to exclude this yubikey example from "all current 2-factor authentication methods"?
They are more secure because they are different per-site and are public-key-based rather than secret-based, so they can't be captured and replayed later, a website compromise doesn't lead to further compromises, and they are phishing-resistant (e.g. paypa1.com can't request PayPal.com credentials).
Passkeys are meant to refer to primary-factor authentication, as opposed to using something like a yubikey as a replacement for SMS OTP or TOTP. The ability to discover available first-factor options for a web domain was something new in FIDO 2 over the older U2F-based keys - I'd expect any security key sold in the last three years to have at least limited support for discoverable credentials.
By default when someone talks about passkeys they mean multi-device, where you back them up (most likely to the cloud) and can sync/restore them to other devices. But modern Yubikeys (and current Windows Hello) support single-device passkeys.
Or to put it a different way - passkeys are meant to be a concept for something equivalent but better than passwords, not a proper spec in themselves. Hence the lowercase 'p'.
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.
Without this kind of cloud sync, you need at least two devices, or you will be locked out if you lose or break one.
The system QR code behavior is for when your registered credential lives on another device. It sounds like you might have not registered anything yet, so you don't have any account or credentials with which to sign in.
Then tried signing in. "Enter the passcode that was sent to <email>." Fail 2 - no passcode was ever sent. (Yes, I tried the resend button multiple times, because I'm not a moron. Yes, I checked my spam folder, because I'm not a moron. I know the HN crowd would have taken great pleasure in explaining the obvious to me if I hadn't mentioned it.)
Even if that had worked, how is copying a code from unencrypted email supposed to be either easier or more secure than a password? Fail 3.
1. It allowed me to auto fill. Both the email and the pass code.
2. The pass code was sent and I received it without issue.
So, not sure what happened to you, but your failures don't seem an issue with Passkeys, but rather just software in general.
Email codes are just the fallback auth method in case no passkeys are supported on the device or the user has lost access to the passkeys. In real world scenarios, this may be secure enough, or fallback authentication could be disabled completely, or secured with Security Keys or other 2FA methods, depending on the use case.
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.
Just tried on multi-device scenario with android and my mac and that worked fine. I'm wondering though, how the biometric data gets associated with my email address.
Don't take my word for it though!
What links are created between all these accounts? Does Google now know that their account B is linked to email A? Does Hankio? Or is that the service provider?
It is up to the site to decide if it wants to accept that authenticator, e.g. if it meets the necessary security requirements. For most sites, they'll accept anything based on user preference.
The site only ever knows the 'kind' of authenticator though (possibly through a cryptographic attestation). The authentication process only releases/uses the public key, not any supplemental information. The site would never see any PIN or biometric information that was gathered locally to release the use of the key.
The site (usually) can't even tell whether it was a PIN or biometric used - just that that 'kind' of authenticator has a particular behavior and particular security reputation/policy/certifications.
webauthn.me has a developer tab that lets you really get your hands dirty.
See also: https://github.com/teamhanko/hanko/discussions/342
As a developer, this appears more like a superficial sales pitch than a technically informing demo.
It might be useful to think of passkeys as a usability extension to webauthn. You no longer need to buy dedicated security devices but can use your existing laptop and phone to login securely to your accounts. I expect my parents will start using passkeys on sites in the next 24 months. I would not have tried to get my parents to use Yubikeys.
So the ability to see or manage passkeys will unfortunately vary by platform, and Chrome's support there will thus also vary. We can only hope this gets more consistent over time.
For passkeys in Google Password Manager, I expect they will (at least eventually) show up right alongside passwords. This is also how it works in the Apple ecosystem.
I mistakenly assumed the "+" thing is built into the email standard.
Additionally, gmail normalize all periods (.) to the mail address without periods.
So your.name@gmail.com yo.u.r.n.a..m.e@gmail.com both get delivered to yourname@gmail.com
Or in other words, it works the same as a password manager today.
There is a slight wrinkle that some platforms may eventually offer to use an internet service during registration for any required device attestations (e.g. no, this is really coming from mobile phone brand X). Your registration process can't require such things if you are dealing with non-internet-connected devices.