Shifting to two-factor auth is hard to do. GitHub recommends the long game

Black Hat Getting people to use multi-factor authentication is surprisingly tough – or unsurprisingly, depending on your opinion of IT users. In any case, GitHub is managing it by playing the long game.

The code-sharing shack declared in March that two-factor-auth was pretty much not going to be an avoidable option by the end of the year.

John Swanson, director of security strategy at the Microsoft-owned biz, was given the job to make the switch. He told The Register GitHub wasn't expecting it to be easy, and decided to roll out the requirement gradually to developers so that it could improve the system for all users by the deadline.

"We did make it a slow burn," Swanson told us ahead of his Thursday talk at Black Hat. "If security isn't easy to use, it isn't really security at all. If you make the user experience unpleasant or too tiresome I think you lose the trust of people. It's the chief challenge."

Swanson has experience in the area since he was one of the team who previously worked on adding two-factor authentication (2FA) on GitHub. The organization has had 2FA as an option for many years, though making it mandatory for 100 million users takes a lot of advanced planning and forewarning, he explained.

The key to making it work was a staged rollout, which gave time to sort out any teething issues and see how the system, particularly the user interface, could be improved. GitHub started by making 2FA mandatory for maintainers of the top 100 npm packages in February last year, and then in November extended that to those with more than one million weekly downloads or those who had more than 500 dependents.

In May of that year the team started warning that 2FA was going to be coming for everyone by 2023 and on March 13 this year, the scheme was implemented. It was a nervous time for GitHubbers, though Swanson said he was a little shocked when the expected protests didn't happen.

"At the moment I'm walking around in a bit of a daze because I expected more pushback and there's been so very little," he said. "We were very willing to slow down and make sure we didn't lose trust."

• GitHub to require two-factor authentication for code contributors by late 2023
• GitHub rolls out mandatory 2FA for loads of devs next week
• RubyGems now requires multi-factor auth for top package maintainers
• Tesla hackers turn to voltage glitching to unlock paywalled features

So far, the results have been encouraging. GitHub has seen a 33 percent reduction in account lockout recovery attempts and a 42 percent reduction in 2FA-related support tickets. Encouragingly there's also been a 23 percent drop in the use of SMS for authenticaton, and it seems more developers are getting the message about its insecurities.

Swanson acknowledged that non-SMS auth is a more secure option, and said that text messages were supported because it's easy to use and there's a large group of people who are comfortable with it, reiterating that if a security system is too much of a hassle then people will just "jump the fence."

He's also particularly keen to see more passkeys used on the site. The technology is maturing, he said. In July, GitHub released the public beta of its passkey authentication system.

Ultimately, the security of both GitHub users and the vast number of applications that rely on their contributions was something that had to be improved to protect today's developers and software supply chains, he said. He urged other companies and organizations to take the step.

"Obviously this shouldn't be something that you send a single email, and you drop it on your entire platform in 72 hours," Swanson joked.

"But you need to think about the cadence, the contents of your communications, and I would really encourage – especially if this is a security led initiative within companies – to engage your internal communications, your public relations folks, your support communities, because they bring in critical perspective." ®