+1

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

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

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.

I too only want to use yubikeys for 2fa.

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

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.

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

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.

thanks @mrniko I now have a system i like

I don’t think it’s a “much more powerful” hacking technique, but I would say that one of the key advantages of security keys over very long passwords is the lack of opportunity for phishing attacks. With FIDO, there really is only your security key that can unlock your accounts, and the credentials cannot be captured by bad actors. The numbers speak for themselves when you look at a company like Google, who switched their employees to security keys in 2017 and has reported 0 phishing incidents since then. I agree that it seems extremely counterintuitive to GitHub to start this huge drive for users to configure 2FA, but then force them to use slower and less secure methods

The closest you could probably get is either using Yubico Authenticator (which unlocks with a security key) or even deleting the code from authenticator app if you wanted to do that, then also adding security keys.

Some password managers also allow saving TOTP codes, so if you use one, as long as the vault also uses 2FA, that would be a good workaround.

The closest you could probably get is either using Yubico Authenticator (which unlocks with a security key) or even deleting the code from authenticator app if you wanted to do that, then also adding security keys.

You'd think that you could just delete the TOTP code from your authenticator app right? But NO, a few weeks later GitHub will make you authenticate via the TOTP code and won't let you login to GitHub (even with your perfectly valid security key) until you reconfigure TOTP to work again and give it a valid code. It seems GitHub has chosen the approach of babying their users and assuming that they have set their authentication up wrong. I just want be locked out if my security keys don't work, and I don't have one of my backup codes. Should be a very simple idea but all of these stipulations that GitHub has come up with make it so unnecessarily complicated!

I agree that we should be able to deactivate TOTP if we have set up more than one security key.

@clwgh @joshuawalker Just to give a note that "passkeys" and "security keys as 2FA" are two different things. While the industry is slowly accepting passkeys as an alternative to password login. Passkeys are not a good choice for everyone.

And be careful that passkeys ≠ 2FA. Passkey is only a single factor authentication while the passkey-supported device (your smartphone or laptop) may provide an optional second factor (PIN, face recognition, fingerprint sensor, etc.)
The keyword is optional, so passkey is not a 2FA by itself.

The main drawback of using passkeys is that you have to sync the secrets across devices. That reason alone makes it not a good replacement for passwords, for certain people.

For me personally, I would just rely on a strong password, and YubiKeys for the occasional second factor auth. I don't trust other methods.

I get the impression that GitHub wants to end up supporting some variant of passkeys as a primary 2FA approach, and this will allow GitHub to market the new account feature, while avoiding having to manage the process for loss of 2FA, instead handing that work over to the passkeys provider.

Watch as lots of providers take this third-party hands-off approach to account security over the next couple of years.

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

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

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.

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

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.

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

@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?

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

do not do this. it starts asking you for the security code as a 'check'

Moving my engineering team over to Gitea.