[Feedback tracking] Passkeys public beta feedback

[hpsin]

This discussion is for feedback on the public beta of passkeys on GitHub.com. Please let us know any issues you run into, ideas you have to improve the feature, or questions you might have about it.

Handy docs

• About Passkeys
• Launch blog post
• Chrome's OS support matrix in case you see a warning that passkeys aren't supported in your browser.

Known issues

• Firefox currently registers as not being passkey compatible. Security keys registered after 2019's move to WebAuthn from U2F can be upgraded and still work in Firefox as a second factor, but won't be usable as a passkey in Firefox yet. Security keys registered prior to August 2019 should be deleted from your account and re-registered in order to convert them to a WebAuthn registration, and then can be correctly used in Firefox as a second factor.
  • As of July 13, 2023, we've updated our logic to allow an attempt at passkeys if WebAuthn support is detected. This means that Chrome on Windows without Hello, Chrome on Linux, and Firefox will all show a message indicating that you can attempt to use a passkey, and it'll likely be a passkey on another device.
• Safari shows old WebAuthn registrations for platform authenticators as valid passkeys, but they do not work. Safari has supported passkeys for quite a while, and all security keys registered in Safari in the last year or two will be presented in the browser as passkeys, even though they are not. When you upgrade these to passkeys, they'll stick around and still be presented in the autofill dropdown. You'll want to delete these registrations from Safari to make them go away.
• If you have not set up Windows Hello, your browser may not tell GitHub.com that you have an available passkey. If you see a warning that your browser doesn't support passkeys, and you are on Windows, try setting up Hello and trying again. As of July 13, 2023, you're also able to trigger the passkey flow anyhow and use a passkey on another device.

Preview limitations

• The Sign in with a passkey button on the login prompt only appears if the right cookie is set on the browser, which signals to us that you're in the feature preview (we can't tell which user you are until after you sign in, otherwise). However, once this ships to GA we'll have the Sign in with a passkey option available to everyone, regardless of cookie state.
  • If you want to force the button to appear, you can go to https://github.com/login?passkey=true

[nschloe]

Using Chrome 114.0.5735.198 on Linux, and I'm getting

You are using a browser or device that does not support passkeys.

The result of PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() in the console is

[TimWolla]

@hagould The button is now there, but the YubiKey I want to register as a PassKey is already set up as a Security Key for 2-factor, thus can't be registered again. No upgrade flow is offered (neither in settings, nor on login).

[hagould]

"You are using a browser or device that does not support passkeys."

We'll remove the isUVPAA restriction tomorrow (~9 hours from now) so folks won't be blocked by this anymore.

Edit: this has been done

a passKey is already set up as a Security Key for 2-factor, thus can't be registered again

That first request to create a passkey needs to return an InvalidStateError because of a conflict with an existing credential in order for us to start you on that upgrade path - if the client you're using is handling that scenario differently you'll have to delete your security key and re-register it as a passkey.

[TimWolla]

That first request to create a passkey needs to return an InvalidStateError because of a conflict with an existing credential in order for us to start you on that upgrade path

Ah! It appears to work in Google Chrome, but not in Firefox. I've been able to upgrade the YK 5 using Chrome now.

[frank42hh]

Hi @hagould, thanks so far for this, but I hit the same problem regarding Chrome + Linux. Can you enable the "try anyways" work-around for my account too? I have a working Yubikey that wants to be used by me.

[nils-s]

@hagould Thanks so much, works great 🎉 successfully upgraded two already-registered Yubikeys to passkey login (even without deregistering them first, best passkey enrollment experience so far 👍 )

[joseph-aha]

@hpsin Would you please share the justification or threat model for passkeys to automatically bypass 2FA? It seems less secure to fully trust a single passkey provider compared to a traditional password manager with a separate 2FA device.

With password+2FA, even if my password manager is completely compromised, my 2FA enabled accounts are protected from unauthorized login because my 2FA secrets/codes are not stored in my password manager. With a passkey and GitHub's implementation of 2FA bypass, the passkey manager is entrusted with the key and also trusted to perform the second factor auth, but is now a single point of failure/vulnerability.

I would like to be able to still require 2FA on my GitHub account (which I can configure on a separate device) and just use passkeys as a password replacement. I would also like to be able to enforce this for my GitHub organization members.

[joseph-aha]

@hpsin As an organization administrator with GitHub 2FA enforcement setting turned on, I don't agree with passkeys being counted as GitHub 2FA. A problem from a security and compliance perspective is that with TOTP 2FA, GitHub is checking the second factor, but with passkeys, GitHub is not directly checking the second factor but is trusting that someone else (the passkey manager) does it. This weakens the security story from an organizational trust perspective because the GitHub 2FA enforcement setting in an organization is not directly being checked by GitHub.

Since 2FA may not be checked by GitHub when passkeys are in use, I am very hesitant to approve/allow passkeys in our organization even though I have nothing against them in principle. I request that use of passkeys does not automatically count as 2FA for the organization membership 2FA enforcement setting (or provide some additional settings to us).

[timcappalli]

@joseph-aha the primary reason that concepts like 2FA and MFA even exist, are because in a pre-passkey world, the primary credential / factor was phishable. Passkeys are phishing-resistant. If you deployed MFA/2FA solely because of credential phishing, passkeys solve your problems.

RE: "someone else", in FIDO2/WebAuthn (the gold standard for strong, phishing-resistant authentication) authenticators are responsible for user verification, not the relying party.

[joseph-aha]

@timcappalli We did not deploy MFA/2FA solely because of credential phishing. I think there are other threats mitigated by MFA/2FA when using a modern password password manager with sync. Compromise of a cloud password manager does not lead to compromise of 2FA enabled accounts if the 2FA TOTP secrets are stored separately. However, with passkeys counting as two factors for GitHub, it is theoretically possible for cloud password manager compromise to result in account compromise.

I appreciate the dialog and explanations and I am not trying to be recalcitrant. I understand that it will still be possible for users to configure more and less secure versions of passkeys in the same way that it is possible for users to configure more and less secure versions of passwords and MFA/2FA. In general, I agree that passkeys will be better for most users, but it seems worse than some of the more secure configurations with MFA/2FA. It also seems like a potential step backwards for GitHub organizations enforcing GitHub 2FA.

I am trying to navigate the implications of shifting responsibilities to the authenticator that were once enforced by the relying party. I am having trouble justifying this shift because automatically counting as GitHub 2FA seems to unnecessarily unify two concerns that appear more secure when separate. Perhaps this will just become an accepted reality of using passkeys that almost everyone accepts, but it still seems odd to me to count this as GitHub 2FA without any configuration options.

[timcappalli]

@joseph-aha how are you preventing users from storing their OTP seeds in their password manager or redirecting SMS-based OTPs to the same device where the user is accessing the service?

A passkey without any user verification is still an upgrade from two phishable methods.

[joseph-aha]

@timcappalli Primarily through user training and streamlining the separate device flow. We have disabled SMS-based OTP wherever possible and also train to use app-based 2FA wherever supported. Since some of our systems require a specific third-party 2FA app, we know that it is at least available for users to also use for plain TOTP. However, it is not fully enforced through technical controls (hence my reference to "more and less secure configurations").

[Firstyear]

It appears as though in this you are forcing resident-key=required.

This is a problem because almost CTAP2 devices have extremely limited storage for resident keys. It is common for this to vary from 8 to 32 key slots. As users enroll their devices to sites or have multiple accounts, this will rapidly consume that space. To make this worst, as most devices currently on the market are CTAP2.0, they have no way to delete a resident key once created. It's also key to note, many users of github will be early adopters and will likely use yubikeys and other devices which this issue affects.

Since you have no way to prevent a CTAP2 device being used (since to allow caBLE means you allow roaming authenticators, which also allows usb-hid), you very likely will contribute to user keys running out of storage with this scheme.

There are many ways you can proceed that don't force key residence! Many platform authenticators under "discouraged" will create a resident key anyway, and will set that in their credProps allowing the usernameless workflow (which you can trigger in the username field with conditional ui) - but you should also allow passwordless workflows where a user enters their username, conditional ui isn't completed, then you can look up the user and prompt for their non-resident key. This will allow users to use "passkeys" without damaging their devices, while still allowing usernameless as an option with conditional ui.

[pro-sumer]

Seems I'm lucky, my 5 Ci has firmware 5.2 and the 5C NFC keys have 5.4.

Thank you for teaching me something new about passkeys / YubiKeys!

[schaarsc]

one of the big advantages of FIDO2/webauthn is the possibility to give users the choice between HW-Token, Smartphone or other devices.

However, if resident key is mandatory then there is no choice (not really). HW-Tokens are expensive and have limited space for resident keys. Besides the cost, no one wants the hassle to work with a bunch of HW-Tokens on a day to day basis.
Then we are back to needing a Smartphone for logins and in this case I can as well stick to username/password + TOTP..

@hagould please consider adding a login flow for "username + HW-Token" during the BETA testing, before any final decision.

[Firstyear]

You're welcome. For more context, see https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/

And yes @schaarsc you are correct. This does remove choice. This was raised in the w3c webauthn wg, but it was "not considered an issue" by the powers that be. So we have to hope that github acknowledges this problem and decides on a flow that doesn't brick peoples keys.

[hagould]

We'll need to redesign our login experience first - until then we can only support passkeys as discoverable credentials. For now you can stick with TOTP for 2FA or register and use your hardware keys as "security keys" without having to worry about storage limits.

[Firstyear]

Sure. I hope this means you'll support "non discoverable" passkeys in the future here. I am always open to further discussion and consultation if you wish (I'm the maintainer of the webauthn-rs library and extremely involved in this space).

[kerolloz]

In the feature preview, the Add a passkey button is not working (not clickable)

[Thereache]

I am also

[e12345ewf]

bloons clicker wont update :{

[jandsonrj]

There may be a technical issue with the functionality of the 'Add a passkey' button in the feature preview. I recommend trying to refresh the page, clear your browser cache, or check for compatibility issues with browser extensions. If the issue persists, please get in touch with technical support for further assistance.

[invisiblepancake]

they are scamming api keys now? just to sell to an person that would get caught? i hope u get api keys get exoensive. i would restart my account

[CarlosDavidFelizRamirez]

So funny Xd

[Mitsuma]

Chrome 114.0.5735.199 (latest public) is not passkey compatible?
Pretty sure it should be but its showing me incompatible browser.
Any plugins that could mess with it are disabled on github.

[timcappalli]

Would be nice if this worked with Google's passkey and not require Windows Hello, as that often isnt available for your regular PC.

Windows Hello is available on every Windows 10 and 11 device.

[Mitsuma]

@hagould Worked fine to add and to login, I was able to use google's passkey to use my phone as a passkey.

[isgj]

You can use the passkeys without a platform authenticator in chrome, I already use them in other apps.

Linux users can use passkeys from another device such as an Android phone or an iPhone by scanning a QR code.

https://developers.google.com/identity/passkeys/supported-environments#linux

[TheCrazyMax]

Yes but for Windows 10, you need at least 22H2. On my work computer we still have 21H2 so, sadly, it's not supported yet there. But on my own Windows 11 it works like a charm since october :)

[grawity]

I have Windows Hello added as a "security key" (on Windows 11) – it already works for 2FA and I get the offer to upgrade it to a passkey, but doing so pops up the Hello dialog that requires me to connect a hardware key. This happens equally with Chrome 114 and Firefox 114.

(On the other hand, I've successfully upgraded the Android Chrome "security key" to a passkey, and was able to use it from the same Windows 11 through the bluetooth thingy Chrome does.)

[hpsin]

Thanks for the fantastic report. We suspect this is Windows handling the "Create" scenario differently than the "Use" case - they're hiding the existing registration, and thus forcing you down the path of the only other possible option - a hardware key.

Two things to try -

1. Hit "Cancel" on the first screen to force the browser prompt, and see what the other options do.
2. Delete the Windows security key and then try to "add a passkey". It should then re-allow you to use Windows Hello as a credential.

[grawity]

Hitting "Cancel" in Chrome gives me a selection between a) using Windows Hello (which does the same again), b) using my Pixel phone (via caBLE, I assume?) which worked for sign-in but probably won't help here, or c) QR code (haven't tried this one but I assume it's also only for sign-in). In Firefox, "Cancel" just makes the request fail.

Deleting the device from GitHub's "security keys" seems to have worked (though I also deleted the key from Hello using Chrome's chrome://settings/passkeys, just to be sure); after this I could add it as a passkey normally.

(Though while registering Windows Hello as a passkey, I got two PIN prompts in a row – same for both browsers – but signing in seems to happen normally. Edit: The same happens at https://passkeys.io, so I guess that's a Hello quirk?)

[nidrissi]

Same here - I had to delete the security key first before being able to add it as a passkey.

[pro-sumer]

I don't see the (documented) Sign in with a passkey option anywhere on the GitHub login page...

I checked that page in these browsers:

• Safari Version 16.5.2 (a) (18615.2.9.11.9) on macOS Ventura 13.4.1 (a)
• Firefox 115.0.2 on macOS Ventura 13.4.1 (a)
• Mobile Safari on iPadOS 16.5.1 (a)

Note that I use (the) 1Password (browser extension) as my passkey provider (although I also use iCloud Keychain as a backup).

[Borales]

Got this response from 1password customer support:

Currently 1Password does not give the option for you to choose which account to sign in to if you have multiple accounts with passkeys saved for a website. I can confirm however that this is something we are working on.
On some websites, if you enter the username first, this will tell 1Password which account you would like to fill. I understand that this isn't intuitive and have passed your feedback on to the team. I apologise for the inconvenience this may be causing.

[TheCrazyMax]

On my side with 1Password, it is triggered on many sites, but not on GitHub, it triggers Windows Hello directly without letting me choose.
On other sites, 1Password is triggered directly and then if I dismiss it, it triggers Windows Hello

[pro-sumer]

Apparently 1Password has added account selection for passkeys in their Nightly channel.

PS: the Nightly browser extension is only available for Chrome (Safari & Firefox only get beta releases)

[pro-sumer]

The 1Password Safari/Firefox beta browser extensions got updated yesterday/today and now support selecting a passkey 🎉

@Borales Maybe you can try this for GitHub?

[Borales]

Works perfectly now! 👌 (tested in Chrome with 1pass Beta extension)

[smajchrz]

Is there any separate login page as I can't see "login with passkey" button on any browser on my system, and yes I already registered passkey on my account.

[grawity]

Mentioned in the main post, if you don't have the "enabled the feature preview" cookie you'll need to use https://github.com/login?passkey=true for now.

[austindrenski]

FYI just ran into this after starting to convert security keys into passkeys, and have to say it was a heart stopping moment.

Recognize its called out in the help docs, but this feels like a major stumbling block. Would be nice to see at least a breadcrumb for that query param on the login page soon, @hpsin.

[troyfitzwater]

Will we eventually be able to remove our password from our accounts in favor of using passkeys? Just did this with my personal Microsoft account and have been loving it.

[hpsin]

Way to go on the MSA! It's definitely something we want to support in time too - right now we're focusing on getting passkeys to a place where they're usable by everyone (and this discussion and all its great feedback says we've got some work still), and then we'll look at password removal. It'll be at least a year, I'd say.

[TheCrazyMax]

+1 :) Did it since Microsoft started to offer it and it's so cool. It's definitely the way to go.
And I like that GitHub directly allowed us to login without having to type the username, it's the way to do it with passkeys, but Google is not allowing that yet for example.

[kampka]

@hpsin Since the idea behind Passkeys is to improve security, this is really quite a mandatory feature to have to leverage these improvements.
The password will remain the weak link for as long as it can be used, it may even become worse if people stop paying attention to good "password hygiene" if they believe their account is now secured via passkey.
I would urge you to give this a high priority and also to urge the users to actually disable their passwords.
In addition, this should be enforcable on an Org level as well, similar to the 2FA requirements.

[hpsin]

Hey folks! Thank you all for your feedback and discussion. With your help we've taken passkeys to GA, and every user can now register and use the on GitHub.com.

You can find our launch blog post here, which includes an overview of the changes made since the beta based on your feedback.

If you find additional issues or have more feedback, we're tracking that here.

[pm4rcin]

@hpsin I can't find in the blog post if I can now disable TOTP while keeping recovery codes or is it not yet available?

[hpsin]

At this time you still have to enable SMS or TOTP as part of enabling 2fa, before you can use your passkey for 2fa.

You don't have to setup 2fa to use or register a passkey but in that scenario your account still has a password as it's weakest line of defense.

[nov]

Github passkey implementation requires UserVerification on navigator.credentials.get() calls, but does not verify UV flag in the returned assertion.

Some Apple devices returns UV=false assertion even when UserVerification=required, thus in such devices, users can sign-in w/o local authentication.

[timcappalli]

Some Apple devices returns UV=false assertion even when UserVerification=required, thus in such devices, users can sign-in w/o local authentication.

This is not correct. Apple devices always set UV accurately/correctly. If UV is set to preferred, and the device does not have a biometric sensor available, Apple devices will not ask for UV and respond with UV=false. If UV is set to required and a biometric sensor is not available, Apple devices will ask the user for their system password or PIN and then respond with UV=true.

RP policy dictates how to handle lack of UV.

[nov]

If UV is set to required and a biometric sensor is not available, Apple devices will ask the user for their system password or PIN and then respond with UV=true.

no.

[nov]

RP policy dictates how to handle lack of UV.

I'm saying Github does nothing on UV=false, even though requiring UserVerification=required on get() call.

I'm not asking general answers, but reporting weird behaviour on a specific implementation.

[nov]

It seems Github fixed the bug.
Now UV=false assertions are rejected.

[hagould]

Thank you for reporting

[Trombach]

I just came across an issue that I can't seem to solve. I had my Android phone registered as a passkey and everything worked well. I had to factory reset my phone last night and ever since I can't use my phone as a passkey any more. At first I thought it was the old passkey which caused trouble so I deleted it from Github and from my phone, but when I try to register again it always fails now (Error: Passkey registration failed). I've tried both, setting it up from a Macbook via bluetooth, or via the browser on the phone itself, but nothing works. Passkeys are otherwise working well, for example with my Google login.

[hpsin]

I believe I saw your matching feedback on Google's forums too - thank you for reporting it to them! We'll keep an eye on that.

[Trombach]

@hpsin Thanks for looking into it. Is there any indication on your side why it might be failing? I have since discovered that it does seem like it's also failing on other sites such as PayPal. Interestingly enough, I can still add my phone as a security key for 2FA, but if I try to upgrade the security key to a passkey I get the same error.

[hpsin]

That's particularly odd, and really points to a API issue within the OS. With that I think we have enough to give very specific repro steps to our friends at Google - thank you!

Unfortunately I don't have more to report than that, though - with errors like this we get extremely limited error details given the privacy-preserving nature of passkeys, so we are reliant on the provider to do the right things.

[CyberFlameGO]

It's stated here that hardware keys are ineligible for upgrade to passkeys, unless the hardware key is user-identifying, but I was able to upgrade my YubiKey 5C to a passkey - I believe this is because the security key is FIDO2-capable.

[TheCrazyMax]

Exactly :) since the YubiKey 5 series, they are all FIDO2 capable, which means that they support WebAuthn and passkeys :)

[forkonlyone]

This discussion is for feedback on the public beta of passkeys on GitHub.com. Please let us know any issues you run into, ideas you have to improve the feature, or questions you might have about it.

Handy docs

• About Passkeys
• Launch blog post
• Chrome OS support matrix in case you see a warning that passkeys aren't supported in your browser.

Known issues

• Firefox currently registers as not being passkey compatible. Security keys registered after 2019's move to WebAuthn from U2F can be upgraded and still work in Firefox as a second factor, but won't be usable as a passkey in Firefox yet. Security keys registered prior to August 2019 should be deleted from your account and re-registered in order to convert them to a WebAuthn registration, and then can be correctly used in Firefox as a second factor.

  • As of July 13, 2023, we've updated our logic to allow an attempt at passkeys if WebAuthn support is detected. This means that Chrome on Windows without Hello, Chrome on Linux, and Firefox will all show a message indicating that you can attempt to use a passkey, and it'll likely be a passkey on another device.

• Safari shows old WebAuthn registrations for platform authenticators as valid passkeys, but they do not work. Safari has supported passkeys for quite a while, and all security keys registered in Safari in the last year or two will be presented in the browser as passkeys, even though they are not. When you upgrade these to passkeys, they'll stick around and still be presented in the autofill dropdown. You'll want to delete these registrations from Safari to make them go away.

• If you have not set up Windows Hello, your browser may not tell GitHub.com that you have an available passkey. If you see a warning that your browser doesn't support passkeys, and you are on Windows, try setting up Hello and trying again. As of July 13, 2023, you're also able to trigger the passkey flow anyhow and use a passkey on another device.

Preview limitations

• The Sign in with a passkey button on the login prompt only appears if the right cookie is set on the browser, which signals to us that you're in the feature preview (we can't tell which user you are until after you sign in, otherwise). However, once this ships to GA we'll have the Sign in with a passkey option available to everyone, regardless of cookie state.

  • If you want to force the button to appear, you can go to https://github.com/login?passkey=true

i am try for Passkeys public beta, its working for windows 10. thanks

[Ngochiendev]

I have 2FA enabled with OTP stored in my iCloud Keychain and additionally is my phone number verified. after i use fingerprint key on my macbook there is an error with passkeys. Can anyone help me with this problem?

[puttaananj]

Is the Conditional UI API not implemented as demonstrated in the blog post?

Thanks to expanded browser support, your browser’s autofill system can automatically suggest that you use your passkey to sign in, right from the login page.

This would help to circumnavigate the issue of lack of "login in with passkey" on login page by suggesting passkey in the autofill form itself.

[hpsin]

Right now conditional UI is also linked to the cookie we save to know you're in the passkey beta. A major problem is that some browsers will claim they have a passkey for the user, even if it's not one we've registered - they'll show it for the user, they'll try to log in with it, and it'll fail. If you force passkey support by going to https://github.com/login?passkey=true, you'll get Conditional UI.

[MichaelTornberg]

Well, I'm not giving away anything biometric, because god forbid that data ever leaks. Then that identifier is leaked for life. And if in the long run only a hardware key is to be used as an option.. you'd better be prepared to give me options to secure access to my account if a hardware key access is lost for whatever reason. In short, doing away with passwords is a terrible idea. It's literally waiting for Murphy. I would suggest enforcing strong generated PWs + 2FA instead. Chrome for instance have a military grade generator built in.

[pro-sumer]

With passkeys you only share a public key with a service (like GitHub). The private key remains on your devices and is the one protected by biometric data. In case of Apple devices the biometric data is stored pretty safe (only on the device, cannot be read by malicious software): http://support.apple.com/kb/ht204587

[pro-sumer]

• I can "upgrade" my 1Password and iCloud Keychain "security keys" to passkeys
• I cannot "upgrade" my YubiKey (5Ci, 5C NFC) security keys to passkeys

Is this expected behaviour?

(I expected that I could use YubiKeys as passkeys as well)

[pro-sumer]

I still need to learn more about this; is “user verification” entering a PIN for my YubiKey?

For some sites I have to do that, for others not (so I thought it was the site that configured this; not me?).

PS: I’m (mainly) using Safari (on macOS) and sometimes Firefox (but never Chrome/Edge).

[Firstyear]

Yes, UV is where your device internally verifies not just possession but that "it is you who is holding this". That's what makes these self contained MFA.

The presence of UV is requested by the site at the other end - some send discouraged (they just want you to touch in and assert presence). Others want UV via required to assert it's you there at the device.

Github will require UV here because passkeys are acting as a "self contained multifactor authenticator".

[pro-sumer]

The PIN is (as I expected) already set:

➜ ykman fido info
PIN is set, with 8 attempt(s) remaining.

[pro-sumer]

Oops, RTFM:

Cross-platform authenticators (such as hardware keys) cannot be upgraded, but you can still register a hardware key as a passkey, so long as the hardware key is user-verifying.

[pro-sumer]

I have indeed successfully "upgraded" all my YubiKeys to passkeys, by manually "adding" these existing security keys as passkeys.

I'm a bit surprised that I had to enter the PIN twice and touch the key five times for every single YubiKey (complicated flow?).

[pro-sumer]

When logging in using a passkey, Safari shows me two passkeys for a single GitHub account. However, only one works; the other one gives this error:

Unable to sign in with your passkey.
Please sign in with your password.

Surprisingly, there's only 1 github.com entry in the Passwords section of System Settings. There's also only 1 github.com entry in the Passwords tab of Safari's settings. In fact, both are the same entry, because renaming one immediately renames the other as well.

Where can I find the other invalid passkey and how can I delete that one?

[pro-sumer]

• When I deleted the single (iCloud Keychain) passkey in Passwords, it was gone in both System Settings and Safari (no GitHub entries visible)
• However, there was still one (iCloud Keychain) passkey offered by Safari for login - the invalid one, because all login attempts using that key fail
• I then added a new (iCloud Keychain) passkey; Safari now offers only one now - the valid one!

[nileshprajapati]

Simple process iOS however when adding to iOS keychain. The GitHub passkey is added as new password entry and not to existing GitHub password.

[hagould]

There's more context on this here - long-short is that I'm not sure how much control we have over this since we support login with username or email address, but we register passkeys under your username. Was your initial password entry linked to your email address, and is your new passkey entry linked to your username?

[nileshprajapati]

I managed to the issue by renaming the new entry from username to email. Both GitHub passwords merge together with iOS keychain.

[pro-sumer]

• I have upgraded my (2FA) passkey and security keys to the new "real" passkeys (log in without username & password).
• I also (still) have passkeys configured as the preferred 2FA second factor.

However, when I log in (old-fashioned) using username/password, GitHub is always using the GitHub mobile App (for iOS) instead of a passkey as 2FA second factor.

Is this a bug?

Or should I (re)add the passkey as a security key for that?

[hagould]

What browser/OS are you using?

When a browser only has partial WebAuthn support (or we're not sure if a passkey has been used from that device before) we're sending users to their next best factor first instead. I can look into this now, we initially did this try to reduce friction but since we're allowing passkey registration from browsers with any level of WebAuthn support it's worth revisiting.

[hagould]

I let my Mac automatically clear all cookies as soon as I quit any browser...

This + "or we're not sure if a passkey has been used from that device before" is the reason. I won't have any changes out for this before next week but you can get around it by leaving one credential as a "security key".

[pro-sumer]

There’s nothing to “leave”, since every single credential was removed as security key when I added it as a passkey.

I will try (re)adding one as security key (later today).

[pro-sumer]

I will try (re)adding one as security key (later today).

That's harder than I thought: 1Password wants to add a new passkey then, instead of supplying the existing one.

I'll wait for your update.

[hagould]

Your 2FA preference should be respected now without requiring the cookie hint - let me know if you see any other issues.

[vero0881]

I constantly get the message: Passkey registration failed. I am running macOS 12.3.

[hagould]

Could you try https://webauthn.me/ as well?

[na4ma4]

I found something that's not really a bug, but it's part of the authentication flow, if I login and get to the 2FA screen, then hit back, and then click "Sign in using a Passkey", I get the following page.

It's probably the re-use of the authenticity_token in the login form, but a better error message might be helpful.

[HotCakeX]

I love it, works perfectly on Windows 11 and Edge browser (both latest stable versions)

[fu-w]

💯

[lazytownfan]

I tried the passkey upgrade directions for my 2FA security keys, but the passkey registration failed.

I was using the SoloKeys Solo 1 USB-A, Solo 2A, and Solo 2C.

[hagould]

Depending on your OS you'll have to delete those 2FA security keys first before they can be configured as passkeys.

[froilaaaaan1]

I'm using the latest chrome v115 but it seems like I can't set it up here. any fix to this issue? or am i the only one who has experienced this issue?

[hagould]

Are you trying to register a credential that's already being used as a 2FA security key? Depending on your OS you may have to delete that registration first before it can be configured as a passkey. Otherwise, could you try out https://webauthn.me/ and get back to us with any behavior differences?

[Ngochiendev]

I have a similar situation