GitHub 2FA plan adds SMS, account lockout safeguards
GitHub has added SMS support and fresh account lockout prevention features to its phased rollout plans as it prepares to implement a 2FA requirement for accounts beginning Monday.
GitHub's 2FA requirement will become effective for early enrollment groups starting Monday. The software development service provider has divulged further plans to guard against account lockout and expand options for users.
The rollout details come under GitHub's plan, disclosed in May 2022, to require all developers that contribute code on GitHub enable two-factor authentication (2FA) by the end of 2023. Two-factor authentication is a system in which users must respond to a message sent to a separate device, such as a smartphone via an app, a personal device that supports face or fingerprint recognition to access, or a physical security key. This approach to authentication is meant to thwart software supply chain attacks by preventing attackers with only account credential information from accessing GitHub accounts.
Now in addition to an official start date of March 13 for 2FA enrollment, GitHub has indicated it will support SMS text messages as a second factor for users. It also strongly recommends using a time-based one-time password (TOTP) app and hardware-based security keys.
Another new detail of the rollout plan is support for an additional factor, including SMS, beyond a smartphone TOTP app or security key to ensure users don't lose account access. Finally, a user who loses account access will be able to unlink a preferred email address from it and start a new account.
This new flexibility is potentially risky, GitHub users said. But it is understandable as GitHub looks to usher millions of developers worldwide into 2FA. SMS is now considered less secure than other second factors, a GitHub blog post this week acknowledged, because attackers have ways to intercept such messages using techniques such as SIM card swapping.
"There are still parts of the world where hardware tokens and such are just not feasible, or maybe they don't have [smartphones]," said Reed Loden, vice president of security at Teleport, a secure access vendor. "GitHub is trying to be the central hub for development for the entire world … so it may be necessary to support that as an interim step. Though I would love to see SMS completely removed at some future point, just because of how insecure SMS is."
Another GitHub user contrasted GitHub's SMS support with Twitter's stance on SMS-based 2FA, which the social media platform eliminated on Feb. 15 for non-paying users.
"What Twitter has done by disabling SMS 2FA unless you pay a premium is not the way," said Rick Rackow, senior service reliability engineer at geolocation tech company TomTom in Amsterdam. "Pointing the issues out but leaving the decision up to the user is significantly better, so I like the GitHub approach."
An update to GitHub's official blog in December also included information about a planned checkup for GitHub.com users 28 days after they enable 2FA. The checkup will give users a chance to reconfigure 2FA if they've misplaced second factors or need to reset a password.
GitHub's 2FA rollout details
Users in early enrollment groups will receive regular in-product reminders and email reminders to enable 2FA for 45 days before their enrollment group's deadline, beginning Monday.
After that, the following applies:
Users have seven days to enroll in 2FA from their first sign-in to the GitHub platform after the deadline.
Up to 28 days after enrollment, users can reconfigure 2FA account details.
Beyond 28 days post-enrollment, users who lose account access can unlink their email address and create a new account with it.
GitHub will support SMS-based 2FA, though it strongly recommends TOTP apps and physical security keys.
GitHub will support an additional factor as a backup, so users can have both a TOTP app and SMS number, for example, registered on their accounts.
Users with more than one factor can set a preferred factor to try first. The GitHub Mobile app will also be supported as a second factor.
The 28-day checkup period also introduces some risk, Rackow said.
"Basically it means that anyone who wants to perform an account takeover knows that this will be their last chance," he said. "Most likely, everything's going to be fine though. Generally the whole thing is a great step toward a safer software supply chain for everyone using open source software."
GitHub sets 2FA schedule, tests FIDO passkeys
In November, GitHub began requiring 2FA for maintainers of packages with more than 1 million weekly downloads or more than 500 dependents. The GitHub 2FA rollout this month will prioritize early enrollment groups considered similarly critical, according to the December post. GitHub won't specify exactly which developers fall into these groups. But their selection will be based on criteria that includes enterprise and organization administrators, along with contributors to the top 4 million public and private repositories.
Users in early enrollment groups will begin receiving regular in-product reminders and occasional email reminders to enable 2FA for 45 days before their enrollment group's deadline, beginning Monday. Once the 2FA enrollment deadline arrives, users can snooze that notification for up to seven days before they're blocked from accessing GitHub features until 2FA is enabled.
"Don't worry," said a company blog post this week. "This snooze period only starts once you've signed in after the deadline. So if you're on vacation or out of office, you'll still get that one-week period to set up 2FA when you're back at your desk."
Generally the whole thing is a great step toward a safer software supply chain for everyone using open source software.
Rick RackowSenior service reliability engineer, TomTom
While some GitHub users have objected to the 2FA requirement as an unnecessary hindrance to developer productivity in less-sensitive code repos, others say it's an idea whose time has come.
"For a product like GitHub, you can assume that users are tech-savvy enough to understand how to use 2FA, and it's a relatively easy way to harden up users' security a lot," Rackow said.
GitHub also reaffirmed this week that it is testing passkeys from the FIDO Alliance industry association, which is developing "open standards that are more secure than passwords and SMS OTPs, simpler for consumers to use, and easier for service providers to deploy and manage." Passkeys use public key cryptography standards to authenticate client devices that are protected using biometrics, such as smartphones, eliminating password-based authentication altogether.
Industry experts see passkeys as the ideal long-term means of thwarting software supply chain attacks on the platform.
"Passkeys will remove productivity complaints from developers and is the future of authentication," said Larry Carvalho, an independent analyst at RobustCloud.
In the meantime there have been many examples of hackers using developer environments to gain access to organizational secrets, Carvalho said.
"Developers are under stress to be productive and are promising targets for social engineering hacks," he said. "Any change that lowers developer productivity will have pushback. But I applaud GitHub for enforcing this essential step."
Beth Pariseau, senior news writer at TechTarget Editorial, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.
