How to use only security keys as 2fa?

[alex-meunier]

Hi,

I have two security keys and I would want it to be the only source of 2fa for my account but Git Hub still allows me to authenticate using text messages or recovery codes. It seems I can’t manage these options as I would like to. Moreover this documentation Configuring two-factor authentication - GitHub Docs says

Authentication with a security key is secondary to authentication with a TOTP application or a text message. If you lose your security key, you’ll still be able to use your phone’s code to sign in.

I could accept to keep the recovery codes option, but I don’t want text messages or TOTP application. Can I configure 2fa like this ?

Thanks for reading me 😊

[joshuawalker]

Hey @alex-meunier, we intend to support using a security key as the initial two-factor authentication method without the need to first setup an authenticator app or SMS number, but we do not have a timeframe for when this will be implemented. In the meantime, you’ll have to configure a TOTP app or SMS number before you can use a security key.

[frakier]

so unless you have a cell phone permanently attached to your rear you are out of luck.

[CandyMappr]

Pretty much

[frakier]

Was on a leash for work for a long time, got rid of that thing. I'm reminded as much anytime a bunch of friends/my brother are standing around a campfire, its all peaceful, middle of nowhere and all their phones start ringing as their wives/husband, girlfriends/boyfriends, kids, bosses, etc. start yanking that chain... and then they all answer knowing it is going to completely ruin the rest of their weekend and whatever wilderness class we have scheduled becomes work instead of fun. Github should have made something, even just signed up with something like privacy pass instead of a half way attempt at implementation... just deleted my repositories before i get locked out.

[Ayzzzzzzzzzzz]

yes

[yaxxie-piramidal]

but we do not have a timeframe for when this will be implemented.

its been three years since this was stated and its becoming an unacceptable timeframe with still no timeframe in sight. As others have stated, I want to lose my account if i lose my security keys. Even worse, you're forcing me to periodically use the TOTP even when my security key is present! This is madness!

[mars-risc0]

Any progress on this? I definitely do not ever want to use my phone for authentication, only the security key.

[lriley2020]

Please fix this - forcing me to add another, worse option makes the security key less secure and is just a stupid idea in general

[ChrisHills463]

Please add me to the list of users who wants to only permit the use of security keys to access my account (other than the recovery codes).

[danpaldev]

Having a key is useless with this stupid limitation of yours. If I'm still depending on the worthless TOTP what's the point of having a key? We're not 5-years old who need to be kept away from hurting themselves.

[tmanley1985]

I too only want to use yubikeys for 2fa.

[kevinforrestconnors]

Me too

[DNin01]

GitHub is working on making it possible to use security keys as the primary second factor, based on what they said in a blog post.

In the future, you'll also find security keys there as an option for initial setup on supported devices and browsers.

[emlun]

It's great to see GitHub rolling out the 2FA requirement for active contributors!

When will we be able to choose only security keys and passkeys for sign-in to GitHub? In other words:

• I want to not allow SMS for 2FA to my account,
• I want to not allow TOTP for 2FA to my account,
• I want to not allow GitHub Mobile for 2FA to my account,
  • (but I do want to be able to use the mobile app, just not allow it as a 2FA credential for sign-in on other devices)
• I want to not allow recovery codes for 2FA to my account, and
• I want to be locked out if I lose all ≥2 of my security keys.

It is already the case in practice that my security keys are the only way I can authenticate to GitHub (except for GitHub Mobile). My TOTP credential is stored on the same YubiKeys as I use exclusively as security keys. My recovery codes are stored in my password vault, which is locked with the same YubiKeys as I use exclusively as security keys. Ergo, forcing me to set up TOTP and recovery codes does not make me less likely to lose access to my account. All it does is increase my attack surface. I'm certain this is true of many other users as well.

I'm not asking GitHub to drop support for these authentication methods. But please allow me to delete them from my account if I want to.

Though I guess as a workaround, I could set up a new TOTP key and generate new recovery codes, and immediately destroy both instead of saving them. However that still doesn't eliminate GitHub Mobile as a downgrade attack vector.

[CandyMappr]

I won't be able to log in because I don't have a phone.

[DNin01]

I won't be able to log in because I don't have a phone.

Maybe there's an authenticator app that would work on your computer? You could even use a password manager with a TOTP feature.

[CandyMappr]

Thanks so much for the idea!
I found winauth and i can now use github.
Thank you

[mrniko]

As option you can use Yubico Authenticator. It doesn't require a phone number or internet access. Secret key will be stored in your hardware YubiKey and not locally. Don't forget that the local time on your device should be synced with global time.

[CandyMappr]

thanks @mrniko I now have a system i like

[Perkolator]

I just got the "Your GitHub account will soon require 2FA" email and I don't care about 2/MFA. I have very secure passwords and have them secured very well.

The email mentioned this:

We want you to have the most seamless experience with 2FA possible, so you can choose one or more of the following options:

• Security key
• GitHub Mobile
• Authenticator application (TOTP)
• Text messages (SMS)

But I can see that only TOTP and SMS is offered when enabling 2FA. I could use security keys (would go to same password vault as the actual password for the account.. doesn't make any sense, but if that gets around this github 2FA stuff, great). Otherwise have to think about leaving for another solution.

[Explorer09]

@MasterInQuestion Your argument was about passwords being as strong as the security key. While we refute your arguments, you are now dodging questions.

Don't propose any substitute for security keys while you know little about security keys. This whole thread is about "we want security keys as an exclusive second factor; no TOTP", and discussions about password strengths are already off-topic. Please don't waste our time.

[Explorer09]

@MasterInQuestion You are assuming people's accounts get hacked only because of weak passwords. They aren't. The servers' database can get compromised, leaking all of the password hashes of their users. Long and random passwords can still get defeated by a keylogger if users log in in insecure machines. There are never chances that passwords would be "secure enough". That's what 2FAs are for, d***it.

[John-Nagle]

Has Github dropped support for Yubikeys? The link on how to do this is now a dead link:

Here is a detailed configuration guide for setting up your YubiKey with GitHub for commit verification and for SSH-based authentication.

[Explorer09]

@clwgh Trusting passkeys as a "primary 2FA" is a terrible idea. Passkeys means that you have to always bring the device (phone) with you whenever you log in. I know YubiKeys can be configured as passkeys, but I won't do that for the very reason that I don't want to bring up my key every time I log in (but only doing privileged tasks would require the 2FA).
The convenience factor of passwords is irreplaceable.

[joshuawalker]

@clwgh @Explorer09 GitHub will support using a security key as the initial two-factor authentication method without the need to setup a TOTP app, SMS number, or passkey. We do not have a timeframe for when this will be supported. We will share changes at the GitHub Changelog.

[clwgh]

Thanks for the comment @joshuawalker, it is reassuring that proper keys will eventually be supported as a primary second authentication factor. The lack of timescale, though, is a bit disappointing. Given the 2+ years time elapsed so far, I fear there will be a newsworthy account takeover of an account using security keys, via one of your currently enforced lower quality fallback methods, before GitHub becomes sufficiently focused on this.

[ar-an-ribe]

Has Github dropped support for YubiKeys? The link on how to do this is now a dead link:

Here is a detailed configuration guide for setting up your YubiKey with GitHub for commit verification and for SSH-based authentication.

The (PDF) configuration guide that was originally at that link is downloadable from the Wayback Machine.

[1larity]

A hardware key does not give microsoft access to your mobile phone as a permanent advertising identifier, this makes implementing hardware key support a lower priority than watering the plants in Sat Nad's office.

[Explorer09]

Dear GitHub,
Please allow me to set up Security Keys as an exclusive second factor for 2FA! I don't want any app installed for 2FA, or disclosing my phone number with SMS. Just allow me to set up Security Keys exclusively!!

Since you guys are going to force 2FA to many users (https://www.bleepingcomputer.com/news/software/github-warns-users-to-enable-2fa-before-upcoming-deadline/), it is kind of annoying to me that your site doesn't support a 2FA that best respect the user's privacy!

GitLab have done it right already. There is no reason for you to not do it.

[PyrateAkananto]

In case you own Yubikeys you can use the "Yubico Authenticator" app (in my case the Windows desktop app) to complete the whole TOTP process for the initial 2FA setup at GitHub and store everything related to it (except GitHub's recovery codes) on a Yubikey.

I did that myself and then additionally added the same Yubikey as a "security key" to my GitHub account.

To sign in to GitHub I can now either insert and press the YubiKey or I can insert the Yubikey, launch the Yubico Authenticator app, read the TOTP from the app and enter it on GitHub.

[Explorer09]

@PyrateAkananto Actually I don't trust any software from the hardware key manufacturer. No manufacturer deserves trust. I trust the key hardware only because of its design -- (1.) no special driver or software needed for authentication; (2.) the keys stay offline until I need it for authentication (so the keys can't spy on me).

If I would need a TOTP app, I'll get an open source one (just for better trust), but it's still preferable if no apps are needed.

[netboy3]

Reason: They are black boxes with no way to tell if they secretly send out your TOTP secret to someone else

@Explorer09 Yubico Authenticator does not have access to the secrets. It just sends the current time to the key and receives a code from the key. Also, the Yubico Authenticator is not a "black box" the code is open source and if you're concerned with it you are welcome to audit and/or build it yourself.

[Explorer09]

@netboy3 The average Android users cannot set up a build environment and build code themselves. The fact that Yubico Authenticator is open source doesn't help; users have to trust the official builds on Google Play anyway. The ideal 2FA is that users shouldn't assume trust on any app they installed. In other words, it should be a no-app solution.

[netboy3]

@Explorer09, your trust model doesn't make sense. The "average user" you relate to doesn't use open-source and personally built OS's either. They use Windows desktop and Android/iOS mobile devices that are all closed source. As mentioned previously, Yubikey does not expose TOTP secrets and computes the codes internally, on-key. This means that both the OS and the app have the same access level to generating codes and no access to secrets. What then would make a closed-source OS acceptable and an open-source application not acceptable? How would using an open-source app increase your risk level when the closed-source OS has the exact same access level to the resource?

[Explorer09]

@netboy3 There is no proof when an authenticator app sets up a secret to a key, the app won't keep a copy of the secret and covertly send it to some kind of government agency. When you set up a key for TOTP, the "secret" isn't generated by the key but the website/authentication servers. And the secret could leak to anywhere because the protocol itself is weak. The need to install a mobile app is just a second argument against the TOTP. Just allow me to use U2F exclusively so I can get rid of all of the issues, please.

[CandyMappr]

Also used winauth to set up originally.

…

On Tue, Feb 6, 2024 at 10:04 PM warwick-davis ***@***.***> wrote: i used winauth to setup the initial authenticator and then threw it away after i was done with it. hope that helps. very angry with github for forcing this shit down my throat when my password is plenty secure. i'd be glad to add a yubikey only but nope — Reply to this email directly, view it on GitHub <#22500 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBWQ37JCQXV56N5WN6IWNOLYSLVK7AVCNFSM6AAAAAAQICY43CVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGOJQGM4DO> . You are receiving this because you commented.Message ID: ***@***.***>

[lyronctk]

Two years later, still can't make a security key the sole authentication method of my github account.

Absolutely unacceptable for an organization that houses this much mission critical code.

[lyronctk]

Moving my engineering team over to Gitea.

[kevinforrestconnors]

There appears to be no way to remove TOTP over SMS from my 2FA configuration. I want to only use Ubikey. I also do not want to use recovery codes as if someone gains access to them, my account is completely compromised.

[CPU-Blanc]

Over 2 years on and we still don't have support for only security keys for 2FA...
As others have said, I have security keys, but you're only as secure as your least secure login method, rendering the security keys next to useless. Please let me disable TOTP from my account; offer it as an option, but don't force it on us if we want to use a more secure method...

[YoshiRulz]

Ah, I see this is a known issue.

I'll add that the live documentation is misleading.
The screenshot here shows an account with 2 enabled 2FA methods and there's an option to remove one. I don't even see that dropdown, it's just an "Edit" button.
The passkey setup contradictingly suggests "You must have already configured 2FA via a TOTP mobile app or via SMS," but also "If you use two-factor authentication (2FA), passkeys satisfy both password and 2FA requirements, so you can complete your sign in with a single step."
Buried on the mandatory 2FA docs—which is not where the reminder banner links to—you can find "Currently, we don't support passkeys or security keys as primary 2FA methods since they are easy to lose and do not support sync across a wide enough range of devices."

[DNin01]

    "easy to lose and do not support sync"

    Sheer absurdity.

    Then what's the whole 2FA theater for..?

    Compared to that "easy to sync but also easy to lose/compromise" passwords:

    What "security" does it provide?

A lot of people lose their 2FA credentials, so GitHub has to take that into account, especially since they're making people who wouldn't otherwise adopt 2FA.

Passwords are a little different because it's common knowledge that you have to remember them and that you can usually reset them with an email.

Remember that any form of 2FA is better than not using 2FA, so use what's available while we wait for GitHub to hopefully make security keys a primary option.

[imtiazvive]

Unfortunately, GitHub currently doesn’t allow you to fully disable text message or TOTP authentication while keeping only security keys for 2FA.

As per their documentation, authentication with a security key is considered secondary to TOTP or text message, which means you cannot entirely remove those options if you want to use a security key as your primary method.

While you can keep recovery codes as a backup, you'll still need to rely on TOTP or text messages for 2FA at this time.