Passkeys.io – A Passkey Authentication Demo(passkeys.io)
passkeys.io
Passkeys.io – A Passkey Authentication Demo
https://www.passkeys.io/
120 comments
YubiKey has nice explanation of this [1], it doesn't even store the usernames or anything per service. It just has single symmetric key, from which it derives the stuff.
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...
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...
It supports multiple user names. From what I've seen in screenshots it shows a picker to select the account you want if there are multiple applicable.
What you're asking is if the token can act as a so-called supercookie.
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".
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".
> GA
Probably means google analytics.
Probably means google analytics.
You can use multiple usernames.
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.
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.
Attestation information requires that at least 100k security devices share the same attestation key, so device information can't really be used to track a given user. The proposed devicePubKey extension that helps RPs reason about which device is authenticating with a given Passkey scenario also requires domain-specific DPKs, meaning multiple identities using the same authenticator are indistinguishable as far as WebAuthn is concerned.
Of course, other signals like origin IP or browser fingerprinting can be used to correlate identities.
Of course, other signals like origin IP or browser fingerprinting can be used to correlate identities.
Take a listen to https://securitycryptographywhatever.buzzsprout.com/1822302/... the Q&A helped explain a lot
Yep!
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.
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.
A few things I don't understand:
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?
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?
> 1) How can I share the fingerprint keys between chrome and safari?
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?
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?
[deleted]
1. I don't believe you can, but I could be wrong.
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.
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.
> Account recovery isn't really necessary,
Unless you want to switch from Safari to Chrome, I guess?
Unless you want to switch from Safari to Chrome, I guess?
Part of the design is that every site will support multiple passkeys tied to an individual account. So it will be normal to use one browser to bootstrap registering another browser with a new passkey into your account. This video[1] by the FIDO alliance shows what that process will look like with a bunch of different OS and browser combos.
[1]: https://www.youtube.com/watch?v=SWocv4BhCNg
[1]: https://www.youtube.com/watch?v=SWocv4BhCNg
I would assume so, but I'm not 100% sure. I personally haven't yet messed with Passkeys much aside from use on a couple of sites that have implemented them.
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.
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.
The keys aren’t stored in the browser. The browser just forwards to the hardware.
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.
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.
I use both chrome and safari, and hate they don't use the same password store anymore (chrome used to just use keychain).
But on iOS, you can at least fill in passwords using chrome as well
Watch the video linked below by psanford
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
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
Any idea how are Password Managers, such as 1Password/Bitwarden/Keepass, thinking of integrating or competing or co-living with Passkeys? I can live with something like 1Password but my wife and kids will be more suited and happier with Passkeys.
Bitwarden already support regular WebAuthn for 2FA[0] to log in. They have an active request for Passkey support[1]. It seems like they want to include these inside of their own service too, as the storage provider.
[0] https://bitwarden.com/help/setup-two-step-login-fido/
[1] https://community.bitwarden.com/t/unlock-bitwarden-with-2fa-...
[0] https://bitwarden.com/help/setup-two-step-login-fido/
[1] https://community.bitwarden.com/t/unlock-bitwarden-with-2fa-...
They support WebAuthn to log in to Bitwarden, which is very different from supporting WebAuthn to authenticate to sites.
That’s exactly what I said, “to log in”. They’ve also stated in many places over time their interest to be the holder of keys for these things too, including as a reply to the parent of my comment :).
I know, I'm clarifying that "support WebAuthn to log in" means "to Bitwarden". I'm really looking forward to them being a soft FIDO2 client.
If I understand what I've read correctly, 1Password nightlies already have support for webauthn, but it's certainly not something they advertise as ready for general usage.
https://blog.1password.com/1password-is-joining-the-fido-all...
https://blog.1password.com/1password-is-joining-the-fido-all...
We will try to support it (and I'm aware of similar work by some of our competitors)
https://www.theverge.com/2022/8/31/23329373/dashlane-passkey...
https://www.theverge.com/2022/8/31/23329373/dashlane-passkey...
They could implement a virtual authenticator, emulating a TPM or security key and running entirely in software. Of course, this nullifies several advantages of FIDO.
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.
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.
Seems like Safari (both mobile and desktop) is actively hostile to Passkeys.
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
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
[deleted]
Yeesh. I thought the whole point was to make this easier? How am I supposed to take a photo of my phone screen?
This is the huge downside of passkeys in my view. You must subscribe to some sync solution, and apple/Google/Msft have a tight grip on it it seems, forcing users to use their own secrets sync solution.
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....
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....
You can't. I tried to screenshot the QR code and it disappeared immediately prior to screenshoting. It's a modal screen similar to Apple Pay one.
The demo is just using OTP sent to my email, which essentially makes my email a password manager, and now a much higher value target.
Your email is already both the password and 2fa reset for the vast majority of services... including things like bank accounts.
Email access is basically total access.
Email access is basically total access.
That's a good point. It's annoying to have to check email for a code for each login though, compared to 1Password autofill w/password and TOTP.
Email OTP is just the fallback authentication method of the demo in case a user does not have access to the passkey(s) anymore. Depending on the real world scenario, fallback authentication may either be completely disabled as soon as passkeys are widely available, or protected by e.g. a Security Key or other 2FA methods.
There's a different user experience in Safari on Ventura -- it prompts for my TouchID.
This completely fails on Linux (doesn't even pop up the dialog for my FIDO2 key), even though WebAuthn on e.g. https://www.pastery.net works fine (and works fine with Passkeys on my Android phone).
Firefox is unfortunately a behind on support for this technology. I believe at least one password manager (Dashlane) has shipped a web extension that would polyfill the missing bits on Firefox.
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.
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.
Just looking at the table at the bottom of the page, "where can passkeys be used", Ubuntu is the only Linux distro listed, and it does not support Passkeys.
Yes, but it supports WebAuthn, which works fine, so I'm confused as to why this site is Passkeys-specific and doesn't use WebAuthn, which, as far as I can tell, is a superset.
Currently, only platform authenticators are supported to create passkeys with. Support for Security Keys is in development and will be available soon. Certain combinations of Linux distros and browsers will then support passkey creation as well.
I don't think I understand passkeys. The best I could make out is that it uses an asymmetric key pair for authentication. How is this different from self-signed TLS client certificates (like the ones used in Gemini protocol) or CertFP used in IRCv3?
The difference is that: 1) this is accessible and usable by anyone running a modern operating system+browser. mTLS client certs need to be provisioned which is one of the major reasons why it is only used in enterprise settings. And 2) passkeys and WebAuthn are privacy preserving features. You can't track users across different websites with FIDO2 devices (mTLS does not preserve your privacy at all). This was one of the core principals that went into the design of FIDO(2) from the beginning.
Client certs as implemented on Gemini and IRC are self-signed. They are enrolled on the service after they're created. They don't need enterprise level capabilities. In fact, even the creation of these certificates are automated on many clients (eg: Lagrange Gemini browser, soju IRC bouncer). You don't even think of them as certificates. They're considered as identities.
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.
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.
Passkeys are indeed similar to that approach. There's no CA infrastructure, so they can be considered "self-signed certificates" (though they do not present as certificates, and currently cannot be used for TLS to my understanding, though I don't think there are technical reasons you couldn't wrap them in x509 metadata and use them as such it's just not a core use case), generated per-service, and enrolled as they are created. Passkeys add a couple enterprise features back in than just "raw self-signed certificates" in the form of optional "attestations" designed in a somewhat privacy-preserving way to prove the type of device that owns the key and in deeper enterprise modes the serial number of the device.
Because here the private key totally inaccessible, stored on the user's authenticator device, which is analogous to a certificate authority in this case. Part of the WebAuthn spec provides for methods for trusting (or distrusting) authenticator apps, and presumably browsers themselves will assist in blocking untrusted authenticators as they do with CAs.
When signing up on a Windows machine with Firefox it doesn't let me use Yubikey but prompts for a Windows Hello PIN instead. Canceling the dialog doesn't go to the next available method (like it normally does) but just retries once again, after a second cancellation it just gives up. I'd say this makes this whole thing completely unusable, because under no circumstances would I ever want to use a machine-bound authenticator (unless that's the only option I physically have). I really cannot think of any reason, it won't give me any extra security and it will make things needlessly complicated in event of device loss.
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.
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.
Using a physical key in Windows now requires you to enter the pin to unlock your Yubikey (or set a pin) before you can use it to register.
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.
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.
I'm aware about this requirement, and it makes sense. Obviously, I want the authenticator device protected, so I must know the device PIN or password to unlock it.
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...
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...
> I'm aware about this requirement, and it makes sense.
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.
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.
There are yubikeys with biometric readers.
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.
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.
> 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 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.
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.
Entering a PIN is known as "user verification." The point is to prove not just that you posses the key but also that you know a secret about the key. This is better than passwords for a number of reasons. The pin doesn't need to be secure in the way that passwords need to be secure. The pin is only sent between your browser and your FIDO2 device. If you some how learned my pin you couldn't do anything with that unless you also stole my yubikey. And you can't brute force the pin. Guess the wrong pin more than 10 times on my yubikey and the key will erase itself.
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.
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.
> 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...
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.
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.
It asked for my email address, which I provided. Then it said there was no account for that email address, and asked if I would like to create an account. I said yes. Then it said I was logged in. Huh? I didn't have to verify anything.
If emails are being treated as usernames, in a real world usage, they should be verified. But beyond that, no verification is necessary.
For the sake of the demo, email validation has been disabled to make the account creation as simple as possible and to allow fake email addresses to be used.
> passkeys are way more secure and are easier to use than both passwords and all current 2-factor authentication methods
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"?
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"?
Yubikey is included - as a passkey.
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'.
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'.
One question : will the signature generated on a brand new device still conform to the requirements, if I end up losing all my devices? What if I'm signing in on a random public device?
By the latest definition, Security Keys also store passkeys.
I think it protects against someone getting the 2fa code. Passkey talks to the website directly
Does anyone knows if 'passweys' will be implemented in open source password managers like BitWarden or KeyPassX, etc. ? Or do we need to rely on Apple/Microsoft/Google for this to work?
1Password and Dashlane have web extensions which replace any integrated browser support with their own UX and functionality. I do not know the current release state of those extensions.
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.
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.
The specification is fully open and most of the components have already been implemented in various open source libraries. The nice thing about passkeys is that they are just a FIDO2 implementation with a few extensions. That means any site that supports passkeys will also support other FIDO2 implementations, including the existing open source FIDO2 projects.
I guess I’m not understanding passkeys. On my iPhone it’s asking generating a QR code to scan with another device. Is this assuming another device already has credentials? What if this is my only device?
You register a device (authenticator), which generates and registers a new public key. You show up with that again in the future, which answers a challenge by using the private key. So it's just saying "I'm the same device as you've seen in the past".
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.
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.
In the specific case of Apple, your PassKey is stored in iCloud, and so can be retrieved from any Apple device you are signed into.
Without this kind of cloud sync, you need at least two devices, or you will be locked out if you lose or break one.
Without this kind of cloud sync, you need at least two devices, or you will be locked out if you lose or break one.
You can also save it to your phone, you only need to scan another QR code if you want to save it on another device
Do you use fingerprints to unlock your device? The page asked me to identify via fingerprints
Tried entering my email. Fail 1 - doesn't allow autofill.
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.
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.
The demo in it's current state is built with a web component using shadow dom. Unfortunately, most browsers do not support autofill in shadow dom yet. A newer version using light dom will be available soon.
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.
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.
The email and passcode is part of the site registration flow for this particular site (e.g. registration requires a verified email address). Other demo sites like webauthn.io do not attempt to add a 'real' registration flow.
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.
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.
So, not saying what happened to you didn't happen, but as a counter point:
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.
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.
Very nice, a good step towards the future.
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.
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.
From what I remember, your biometric data shouldn't get associated at all. Your hardware uses your biometrics to unlock the onboard enclave / vault and then the process asking can obtain or create what it needs once unlocked. If you don't have biometrics enabled it would resort to your phone password/pin.
Don't take my word for it though!
Don't take my word for it though!
I think you are correct, I took a shortcut there ; my question is more "I used email A to sign in, and used my android creds (incidentally my fingerprint) - which is using my Gmail account B. Now I want to use my apple creds C to signin on my Mac.
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?
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?
The use-case is to create a new key pair when you register an "authenticator" device, and then sign a challenge later to authenticate (prove it is the existing known authenticator).
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.
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.
I am confused as to why there is a hard requirement tied to apple,google,ms accounts. I get that its so they can sync to other devices but what if I do not want them syncing?
At some point, the platforms may open their APIs and allow for 3rd party providers to hook in and do the syncing. It can be expected that most current password managers will do that asap.
I love this in chrome at least I ran into all sorts of issues trying to get WebAuthn to work with touchid and my yubikey... anyone have plain JS example that works?
I second this. I would love to see a raw demo that doesn't hide the internals.
webauthn.io has recently been revamped to support more of the 'passkeys' behavior, such as conditional UI (the password manager/form-fill-like behavior added in certain browsers).
webauthn.me has a developer tab that lets you really get your hands dirty.
webauthn.me has a developer tab that lets you really get your hands dirty.
thanks yeah i tried the webauthn.io but it seems to be in typescript and not very easy to reuse. i'll try webauthn.me
This was, for me, not an effective demo: when I tap “sign in with a passkey” it shows me a QR code to scan with another device. What? (I assume this is because I haven’t created an account yet, but if so, the demo needs to make that about ten times clearer.)
Thank you for the feedback. We get this question a lot, and it is obviously not ideal right now. Things will get much better with passkey autofill very soon, though.
See also: https://github.com/teamhanko/hanko/discussions/342
See also: https://github.com/teamhanko/hanko/discussions/342
Just tried this on iOS 16.1 and when I go to sign in with the passkey it loads a pop up menu with a QR code that I need to scan - but it's on my phone so what am I supposed to scan it with?
Why does it use Apple specific terms like "Touch ID" or "Face ID" or is this now the standard way to talk about fingerprint sensors and face recognition?
This demo would be far more useful if it displayed the public key that was used.
As a developer, this appears more like a superficial sales pitch than a technically informing demo.
As a developer, this appears more like a superficial sales pitch than a technically informing demo.
There are very few opportunities in the wild where you can use passkeys with a real account and not just a tech demo that pops up a WebAuthn modal. We've built passkeys.io to showcase what's possible with passkeys from the perspectives of the end user as well as the service provider. The demo that you can use on the page is very much work in progress, though, and we value any feedback.
Try https://webauthn.me/debugger. It will show you all the gritty details.
Is passkeys just a webauthn implementation? https://webauthn.io is a similar demo I think.
Passkeys are an implementation of FIDO2 so yes, any sites that have implemented webauthn will support passkeys.
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.
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.
How would you go about handing a lost device with this? A passkey reset email which would have a link that you could use to register a new device?
I would really like this tech if they supported third party services to store passkeys in.
1Password and Dashlane have announced support via web extensions. I also really hope we have future platform-level support, so that third party "passkey managers" will work outside of the browser (such as on mobile, within all native apps).
Wouldn't that completely eliminate the security benefits of passkey?
It really depends on your security requirements and where you're coming from or what you're comparing it to. There would be still many advantages over, say, passwords stored in a pw manager, such as no shared secrets across all sites/apps, phishing protection, and far fewer opportunities for user errors.
No, because it already uses a third party service, it just doesn't let you pick the one you want to use. I want to have the option to use a FIDO2 key, for example.
Am I wrong here, or isn't this just a glorified password manager on your phone?
I wish chrome showed me what keys are issued. There's no way to see a list
The platform is often managing things, sometimes with Chrome and the platform splitting responsibilities when the Chrome team adds support for additional options.
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.
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.
Chrome on Android should show easily but it doesn't
[deleted]
Jus a note for the creator. Not all email adresses support the +n thing. Just gmail based
I don't get why this is downvoted. Even if the second sentence is I correct, the first one is correct.
I mistakenly assumed the "+" thing is built into the email standard.
I mistakenly assumed the "+" thing is built into the email standard.
Fastmail supports it too and you can configure postfix and opensmtpd to support it as well.
More than Gmail supports this.
I can confirm it works on MailInaBox. So it should probably work on any installation that uses Postfix and/or Dovecot.
Most providers support it afaik.
Additionally, gmail normalize all periods (.) to the mail address without periods.
So [email protected] [email protected] both get delivered to [email protected]
Additionally, gmail normalize all periods (.) to the mail address without periods.
So [email protected] [email protected] both get delivered to [email protected]
iCloud Mail supports it too
What if your device cannot connect to internet? OTP can work even if device is offline.
If your device has limited network connectivity, it can create new passkeys or use a passkey it already has for interacting with a service. However, it won't be able to synchronize new credentials with any cloud service in multi-device scenarios.
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.
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.
The passkey lives on the device you are logging into the service with, so it implies you have internet access there to be able to log into it in the first place.
I guess you're specifically referring to TOTP or SMS-based OTP. Email OTP still requires an internet connection, for example.
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