GitHub’s Hardcore Plan to Roll Out Two-Factor Authentication (2FA)

You’ve heard the advice for years: Turn on two-factor authentication everywhere it’s offered. It’s long been clear that using only a username and password to secure digital accounts isn’t enough. But layering on an additional authentication “factor”—like a randomly generated code or a physical token—makes the keys to your kingdom much tougher to guess or steal. And the stakes are high for both individuals and institutions trying to protect their valuable and sensitive networks and data from targeted hacking or opportunist criminals.

Even with all its benefits, though, it often takes a little tough love to get people to actually turn on two-factor authentication, often known as 2FA. At the Black Hat security conference in Las Vegas yesterday, John Swanson, director of security strategy at GitHub, presented findings from the dominant software development platform’s two-year effort to research, plan, and then start rolling out mandatory two-factor for all accounts. And the effort has taken on ever-increasing urgency as software supply chain attacks proliferate and threats to the software development ecosystem grow.

“There’s a lot of talk about exploits and zero days and build pipeline compromises in terms of the software supply chain, but at the end of the day, the easiest way to compromise the software supply chain is to compromise an individual developer or engineer,” Swanson told WIRED ahead of his conference presentation. “We believe that 2FA is a really impactful way to work on preventing that.”

Companies like Apple and Google have made concerted efforts to push their massive user bases toward 2FA, but Swanson points out that companies with a hardware ecosystem, like phones and computers, in addition to software have more options for easing the transition for customers. Web platforms like GitHub need to use tailored strategies to make sure two-factor isn’t too onerous for users all over the world who all have different circumstances and resources.

For example, receiving randomly generated codes for two-factor via SMS text messages is less secure than generating those codes in a dedicated mobile app, because attackers have methods for compromising targets’ phone numbers and intercepting their text messages. Primarily as a cost-saving measure, companies like X, formerly known as Twitter, have curtailed their SMS two-factor offerings. But Swanson says that he and his GitHub colleagues studied the choice carefully and concluded that it was more important to offer multiple two-factor options than to take a hard line on SMS code delivery. Any second factor is better than nothing. GitHub also offers and more strongly promotes alternatives like using a code-generating authentication app, mobile push message-based authentication, or a hardware authentication token. The company also recently added support for passkeys.

The bottom line is that, one way or another, all 100 million GitHub users are going to end up turning on 2FA if they haven’t already. Before starting the rollout, Swanson and his team spent significant time studying the two-factor user experience. They overhauled the onboarding flow to make it harder for users to misconfigure their two-factor, a leading cause of customers getting locked out of their accounts. The process included more emphasis on things like downloading backup recovery codes so people have a safety net to get into their accounts if they lose access. The company also examined its support capacity to ensure that it could field questions and concerns smoothly.

Since those improvements, Swanson says, the company has seen a 38 percent increase in users downloading their recovery codes and a 42 percent reduction in 2FA-related support tickets. GitHub users are also making 33 percent fewer attempts to recover locked accounts. In other words, account lockouts appear to be down by a third.

Swanson says the results have been very heartening as the company has started rolling out mandatory two-factor to batches of users in recent months. The effort will continue throughout 2023 and beyond. But all the concern and care that has gone into the process has a specific goal in mind.

“As we approach enrollment for a user, they receive a number of emails spread out over about 45 days, and they also receive site banners when they visit the site that inform them of the changes and the requirements,” Swanson says. “Then they have an option right at the end of the 45 days for a one-time, seven-day opt-out if they must. Maybe they’re on vacation or need to do something ultra-critical to help ease that enforcement point. But after the seven days, you are blocked from accessing github.com. There is no option for an opt-out at this point.”

In their two-factor campaigns, Apple and Google have left some wiggle room for users who want to intentionally and deliberately leave 2FA off. But other than a legitimate and insurmountable accessibility issue, Swanson says GitHub has no plans for lenience. And no one has raised such a concern so far.

“We take every measure we can to try and make folks aware and avoid problems. But at some point, we feel like we have an obligation—and a responsibility—to support the broader software ecosystem and help it be secure,” Swanson says. “And we think this is an important way of doing it.”

Swanson emphasizes that digital platforms need to promote two-factor adoption across the board, but that they first need to conduct research, carefully plan, and expand their support capacity before mandating the protection.

“Though we want folks to join us on this journey, this isn’t something that organizations should take lightly. You need to prepare and get the user experience right,” he says. “If our intent is to normalize 2FA for the broader community, the worst thing we could do is fail and fail visibly.”