[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

[kerolloz]

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

[EloyParga]

nice

[denisfreitas999]

nice :)

[Themeuz]

very nice i like <3

[dalidoshx]

nice!

[byKosta]

💯

[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.

[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 :)

[ricewind012]

will everyone be forced to sign in with passkeys later like with 2fa ?

[hpsin]

Passkeys would need to be universally loved, adopted, and adoptable, well in excess of SMS 2FA, before we'd consider that, since at that point it'd be "Why does GitHub still allow passwords", similar to how people ask why SMS is still supported. It's a matter of equity and support - Passwords and SMS 2FA are sometimes all people can use, and even SMS 2FA isn't particularly usable in all countries, devices, and demographics (students, e.g.). We'll encourage people to use passkeys because they're better than passwords, result in less account takeover, and fewer account lockouts, but forcing people to use them is not something we've even discussed (except in the context of answering this question).

[fdwr]

Passwords and SMS 2FA are sometimes all people can use

@hpsin: Indeed, there are times when abroad where I have only Internet access on some workstation, and no phone service (so no SMS, no phone apps...). So having email verification (where GitHub sends an email with a timed link) would be really valuable. It could even be a second email address besides my main one if sending it my mine email is suspect. So many other services support this that I'm surprised to not see it in GitHub's list of options 😶.

[ghost]

I constantly get the message: Passkey registration failed. I am running macOS 14 DB3 and tried to activate it on Safari. Is Safari on current beta nut supported for Passkey registration?

[ghost]

I have 2FA enabled with OTP stored in my iCloud Keychain and additionally is my phone number verified.
Yes I am using a MacBook Pro. I verify with Touch ID and then I get the message. I will attach a screen recording:

Screen.Recording.2023-07-12.at.17.59.09.mov

EDIT: Using another method than Touch ID like scanning the QR code on my iPhone with iOS 17 results in the same message.

[hpsin]

Thanks so much! Judging from our logs, this is one of two possible errors - Safari isn't signing the payload as we expect, or we couldn't validate it. We're installing the beta and will debug a bit more. Can you follow the steps on https://webauthn.me/ to see if it's successful there?

[ghost]

Everything went through, but one anomaly happened. Last step from browser to Authenticator nothing happens. It stops there. But if you click somewhere else on the site and go back it finishes successfully. All previous steps are finishing almost immediately.

Screen capture attached. (I had to lower the resolution otherwise the file would be too big).

Screen.Recording.2023-07-12.at.19.37.23_2.mov

[TheCrazyMax]

@pottersfield It's normal that it stops there. Once your authenticator signed the request on the previous step and sent it to the browser, there is no need for it anymore in the process :)

[GenilsonDC]

The video/tutorial dont work

[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 👍 )

[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.

[bdougherty]

It is not working for me on Safari 16.5.2 on Monterey 12.6.7. PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() returns true and yet I get:

Happens with MacBook Pro lid open and closed, although I do have the keyboard with Touch ID, so it should work either way. Have not had issues with other sites that use passkeys.

[bdougherty]

@hpsin yep, I can confirm that it is synced and Safari shows the passkey autofill when I click into the email field.

[hagould]

@bdougherty could you update to Safari 17 on Monterey and let us know if the you see an error message when you try again?

Alternatively, If you could grab a screen recording and file a bug through Apple's Feedback Assistant, they might be able to resolve why the touch ID / iCloud Keychain option isn't available.

[bdougherty]

@hagould I will as soon as it's released. Not going to go through the effort of filing a bug with Apple since they never act on them, especially with an OS that isn't current.

Out of curiosity, I created a passkey on my phone and then went back to my Mac to add another one, and now I am prompted to save a new passkey (Safari 16.6). I then removed the passkeys from GitHub and the password manager and I am still able to create one on the Mac. I can't seem to get back to that broken state at all now.

[hagould]

That's interesting. Did you have any credentials registered as a security key with us before? I've definitely seen similar client issues resolve by registering passkeys from secondary devices, but they were "caused" by the user registering a legacy apple passkey with GitHub (around a year ago or earlier, as a security key).

[bdougherty]

I do have a couple yubikeys registered, so maybe that was the cause.

[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)

[kubo6472]

hehe

[eyoung]

Firefox should be allowed with 1Password to store the passkey

[eyoung]

I'm not sure how I got it to work. After initially turning on the preview it told me my browser is not supported. After finding this page and going back to take a screenshot, it showed me the picture I have above and it was working.

[EKami]

Hum ok, and when you clicked "Add passkey" on this page it prompted 1Password?

[eyoung]

That's right. It prompted me to update my existing github login. It does require the beta 1password browser plugin for both firefox and chrome. If you don't already have that you'll need it

[EKami]

Oh, that makes sense thanks. I'll wait for the production release in that case.

[eyoung]

The beta is publicly available and has been working well for me if you want to try.
https://chrome.google.com/webstore/detail/1password-beta-%E2%80%93-password/khgocmkkpikpnmmkgmdnfckapcdkgfaf

[exh-Auster]

First of all, congrats and thank you for the great work! It's really good to see this being released in more places.

I'm using Safari/iCloud Keychain, and Google's implementation allowed me to bind the passkey to an already existing password entry. GitHub's, on the other hand, created a new one with only my username as the "User Name" field. I ended up with duplicate entries – one being only the passkey, and the other keeping the password, 2FA code and notes. Is this by design?

[hagould]

GitHub's, on the other hand, created a new one with only my username as the "User Name" field

Thank you! This is the first I'm hearing about it. If you don't mind me asking, what else was initially in the username field for your GitHub.com password secrets entry besides the username?

[exh-Auster]

I was using only the email address in the username field for GitHub.

Thinking about it now, perhaps I misremembered what happened with Google. It may have been an automatic merge based on the username (which is the email in both passkey and password entries), though I’m not quite sure.

If you guys have any control over how the password manager presents this flow, I’d suggest this approach:

• existing account creating a passkey: ask the user if the passkey should be added to an existing account entry or saved as a new one;

• new accounts (if and when passkeys become default): save it directly as a new entry.

[hagould]

OK interesting. When users register passkeys on GitHub, we set their PublicKeyCredentialEntity name to their account username. I'm not sure how iCloud keychain binds passkey registrations to existing entries, but I could see them using the RP+username info for it. I would take this up with Apple - we don't have any influence over that behavior besides giving you the option of choosing between your email address or username before you start registering a passkey, which is a disproportionate amount of friction for the benefit. I'd say it's up to clients to resolve or prompt folks to merge those types of entries.

[exh-Auster]

which is a disproportionate amount of friction for the benefit.

100% agreed.

Thanks for clarifying, Hannah! Let me say that, apart from that, the experience was perfect. I’m sure you guys will keep nailing it. Congrats again!

[hagould]

If you're still irked by this, renaming one of the username fields to match should trigger a merge of both entries.

[Fei1Yang]

It looks like when the account have multiple Two-factor security keys registered (e.g. Main Key + Backup Key...), only the first security key (Main Key) added via "Add a passkey" will go through the "Upgrade to Passkey" flow, and other keys (Backup Key...) will fail with "You already registered this device." error:

If the the corresponding Two-factor security key entry is manually removed, the registration process can finish.

[Trombach]

Had the same issue and needed to remove my phone as a 2FA key to be able to add it as a passkey

[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).

[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.

[TukangM]

never using passkeys before. little complicated with saved random passwords

[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

[agowa]

What does this feature actually add? I've been using u2f keys for years now. And since recently my browser keeps asking me when signing in if I want to use a passkey or a hardware security key. So what does enabling this feature add/change? Wasn't it literally already working oob?

[Firstyear]

u2f (ctap1) is single factor only (possession). With "passkeys" aka webauthn, this uses ctap2, where the authenticator allows userverification to the device (biometric, or pin for example) that the authenticators secure enclave validates. This is then cryptograhically signed into the response.

As a result, a webauthn authentication is a self contained multifactor operation meaning you don't need password + u2f now. You just need the single pin+touch event to the ctap2 device.

For other devices like iphone/android, they also do similar where the entry of the pin or fingerprint acts as the user verification phase.

This means that these operations go from single factor (possession) to multifactor (posession and [pin or biometric]).

[agowa]

Yea, but you could do that already using the u2f API, so what's the new thing here?
Also u2f keys existed that require fingerprint validation or pin before providing the response.
Also some used u2f keys as single factor before.
Also this sounds only like a change to the u2f device and not the protocol/api...

[Firstyear]

u2f the website didn't validate or enforce the UV requirement. The fact that it would prompt for it was actually a bug in most websites.
Webauthn can however enforce that UV must be present and valid.
As a result, with "passkeys" you can just use the authenticator with it's internal UV, and you can omit the password.

[agowa]

How can it enforce it? It always has to trust the hardware anyway. So if I modify the hardware to not require human interaction, or just emulate the u2f...

[Firstyear]

The UV flag is signed by the private key of the authenticator. This allows the RP (website) to validate the UV bit is correct and valid. u2f was setting this to "preferred" so the browser would prompt for UV but the RP would never actually check that it was set. With webauthn (and what github have done) UV is required to be present in all signed responses.

You can of course write a softtoken (as I have done here: https://github.com/kanidm/webauthn-rs/blob/master/webauthn-authenticator-rs/src/softpasskey.rs ) which can falsify it's UV status. The only person you'd really be "harming" here would be yourself in this case. Generally for most sites, even though a person could do this, most people won't so it's not a significant risk compared to the benefit of users having cryptographic authentication available.

But if you were a website that wanted to ensure this kind of softtoken, modification or falsification is impossible, then you require attestation of the authenticators on enrollment. This provides a cryptograhic attestation chain that the device in use is of a specific make/model that meets your security requirements. Generally attestation completely prevents things like android or iphones being used though, only fido2 security keys are viable here.

[DavidMichaeldomainglobal10365]

Excellence

[DavidMichaeldomainglobal10365]

Thanks

[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.

[Maelstromeous]

Just discovered this and using it with 1password. Works like a charm! Offering positive feedback for once :)

[bingalls]

I don't regularly use a mobile device, so I am trying this passkey feature, so that I don't get locked out of the 2FA rollout.
There is no clear documentation for this feature. One browser does not seem to allow me to add passkeys. Another tells me to use my "security key" with no explanation.
Links to explain more just jump back around in a circle, without explaining more. The UX of this 2FA seems like a scheme to purchase a license to Microsoft Hello, purchase Microsoft Authenticator, or purchase a Microsoft Phone.
"Verify the code from the app" doesn't work, with no explanation. What happens after the deadline passes? Will I be permanently locked out of my account? What additional purchases must I make, to continue using Github?

[Maelstromeous]

@bingalls Microsoft Hello isn't subscription based. You simply need a device that is capable of authenticating you, such as a £30 fingerprint scanner off Amazon.

[bingalls]

@Maelstromeous Thanks for your help. I could not find the instructions to set up Microsoft Hello on Linux, or even on Mac OS. Good to know, that the additional hardware I must purchase is cheaper than the other required hardware.
I'm a bit concerned that, once I pay all this money just to satisfy Github, that, with the limited documentation, should these product(s) not work, I won't be able to get a refund, which is a common policy.

[Firstyear]

The problem here you are running into is that the term is "passkeys" when it should also say it's "webauthn". Webauthn is a standard that describes cryptographic multifactor authentication for websites. There are many classes of "authenticators" or "passkeys" you can use. For example, touchid on your mac is a "passkey". windows hello is a "passkey". A yubikey can act as a passkey (with major caveats on storage limitations). And even some password managers can act as an authenticatro (dashlane, 1password).

So you don't need anything else, just choose your platform authenticator you want to use and go from there. Most properly deployed sites should allows multiple passkeys too. So your touchid on your mac, and a yubikey on a linux machine or similar.

Hope that helps,

[bingalls]

Thanks! I looked at https://bitwarden.com/pricing/ which will be offering passkeys, just after Github locks me out.
I'm not sure, if this requires TOTP (a premium feature), or if passkeys will be a premium.
I don't have touchid nor yubikey. What authenticator software can I install? Any of it Open Source or cross-platform?

[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.

[upmorpheus]

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.

[TheCrazyMax]

Yes, done that on Microsoft since January and love it too :)
I read that it's the plan here as well, but it's divided in phases :) That's the global idea of passkeys overall ;)

[Firstyear]

It won't happen though. There is too much friction being added in chrome and other browser ui's, vendors trying to lock you into their password managers, and passkeys as MS are doing them force resident keys, which yubikeys only support up to 25 of (most keys support even fewer). To make it even worse most security keys once you add an RK you can't delete it ever. So once you have 25 passkeys, you're done - time to get a new key if you have more accounts.

we had a chance to eliminate passwords for ever, and we are throwing it away rapidly.

[ThiefMaster]

It looks like I can no longer select my phone's (or rather Chrome's) builtin webauthn token as a webauthn authenticator on my GitHub account - with my previous phone (before passkey support arrived) this worked just fine. I do NOT want not use a passkey since I prefer both password and webauth instead of just the passkey.

It would be nice if this bug could be fixed.

[Firstyear]

This sounds like a bug in android, not github. Androids webauthn and passkey impls are "confusing and inconsistent" at best.

[ThiefMaster]

No idea. But when I enrolled webauthn for my workplace's SSO (based on Keycloak), it worked fine. On GitHub I just got the USB+NFC options.

[DonEstefan]

I added my FIDO2 USB-token (onlykey) to my github account and upgraded it to passkey. Afterwards I was not able to add my windows hello as a second passkey. The browser only asked for USB-Tokens and ignored win hello completely.
I needed to delete the USB-token from github and then re-add the USB-token but without upgrading it. This was the only way to add win hello to my github account. After adding win hello I upgraded my USB-token to passkey and now both seem to work fine... 🤷‍♂️

[hpsin]

Did you attempt to add the windows hello passkey from the same session that you upgraded the hardware key?

[DonEstefan]

No, @hpsin. I upgraded the hardware key weeks ago. At the time I did not find a way to also add win hello. So I came back yesterday to do more tests (use different browsers, factory resetting the key, ...) and finally found the solution posted above.
Yesterdays solution worked fine within a single login session.

[SaifurRR]

Have you added usb token?

[truthsword]

Just started using passkey, and it is intolerably slow to log in. I've basically given up, refreshed the page, and used 2FA.

Is there a special browser setting to make this work? I use LibreWolf.

[Firstyear]

What browser and password combination?

[truthsword]

What browser and password combination?

I don't understand your question. That was provided in my post.

[VerzatileDev]

It states the Browser in the message - > LibreWolf

• And its most likely slow because LibreWolf is already slow and its not optimized for this specific use case.

[invisiblepancake]

https://github.com/pfptcommunity/pfptcommunity ?