No More Mr. Nice Guy: GitHub Demands Developers Use 2FA

Last year, GitHub’s CSO Mike Hanley announced that all users who upload code to the site must enable one or more forms of two-factor authentication (2FA) by the end of 2023… or else. Many security problems later, GitHub has decided it’s not going to wait. Starting on March 13, GitHub users must begin enrolling in 2FA.

I can only say this: “It’s about time!”

In case you’ve been napping for the last few years, software supply chain attacks have become commonplace. One of the easiest ways to protect your code is to use 2FA. 2FA is simple.

It’s Complicated

Under the hood, 2FA is complicated. It relies on one of three standards: HMAC-based One Time Password (HOTP). Time-based One-Time Password (TOTP), or the FIDO Alliance‘s  FIDO2 Universal 2nd Factor (U2F) standard. But you don’t need to worry about that as a developer unless security, authentication, and identity are your thing. You just need to, as Hanley put it, “enable one or more forms of 2FA.”

Is that so hard? I guess it is. While I haven’t been able to lay my hands on any 2023 numbers, in 2022, only a minority of GitHub users were using 2FA.

Fortunately, even if you’re allergic to 2FA, GitHub is making 2FA idiot-proof. Well, or as idiot-proof as security ever gets.

1. Second-factor validation after 2FA setup: Users who have set up 2F) on GitHub.com will now receive a prompt after 28 days to confirm their 2FA settings. This will help prevent account lockout caused by misconfigured authenticator applications. If you’re unable to get it to work, you can reset your 2FA setup without being locked out of your account.
2. Enroll second factors: It’s important to have multiple accessible 2FA methods to ensure account access. Users can now register both an authenticator app (TOTP) and an SMS number on their account simultaneously. Although we recommend using security keys and TOTP apps over SMS, enabling both options reduces the risk of account lockout by providing another accessible 2FA option.
3. Choose your preferred 2FA method: Users can now set their preferred 2FA method for account login and sudo prompt. The preferred method will be used first during sign-in, and users can choose between TOTP, SMS, security keys, or GitHub Mobile. We strongly recommend using security keys and TOTPs whenever possible, as SMS-based 2FA is no longer recommended under NIST 800-63B. The most secure methods widely available are those that support the WebAuth authentication standard, such as physical security keys and personal devices that support technologies like Windows Hello or Face ID/Touch ID.
4. Unlink your email in case of 2FA lockout: Previously, locked-out users had difficulty creating a new account using their preferred email address, which was associated with all their commits. With this feature, users can unlink their email address from a 2FA-enabled GitHub account in case they are unable to sign in or recover the account. If recovery options such as SSH keys, PATs, or previously signed-in devices are unavailable, users can start fresh with a new GitHub.com account and maintain their contribution history.

It’s Worth It

Let me underline a point GitHub makes several times: Texting, aka SMS, 2FA is better than nothing, but if someone really wants to crack your account, SMS 2FA is the easiest method to crack. Personally, I recommend either a free Google Authenticator or Microsoft Authenticator; the open source Bitwarden; or a YubiKey or Google Titan key.

Yes, I know many of you will find this very annoying. Trust me. It’s worth it. Otherwise, sooner or later, your code repositories will be hacked. It’s not “if,” it’s when. Code security attacks are at an all-time high, and you don’t want to be one of the casualties.