Shifting to two-factor auth is hard to do. GitHub recommends the long game
- Reference: 1691686812
- News link: https://www.theregister.co.uk/2023/08/10/github_multifactor_authentication/
- Source link:
The code-sharing shack [1]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.
[2]
"We did make it a slow burn," Swanson told us ahead of his [3]Thursday talk at [4]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."
[5]
[6]
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 [7]in February last year, and then in November [8]extended that to those with more than one million weekly downloads or those who had more than 500 dependents.
[9]
In May of that year the team [10]started warning that 2FA was going to be coming for everyone by 2023 and [11]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."
[12]GitHub to require two-factor authentication for code contributors by late 2023
[13]GitHub rolls out mandatory 2FA for loads of devs next week
[14]RubyGems now requires multi-factor auth for top package maintainers
[15]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.
[16]
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." ®
Get our [17]Tech Resources
[1] https://www.theregister.com/2023/03/09/github_2fa_requirement/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/blackhatanddefcon&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZNVeBW8kPOtZripRgqpZwgAAAhY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.blackhat.com/us-23/briefings/schedule/#i-was-tasked-with-enrolling-millions-of-developers-in-2fa---here39s-what-happened-32925
[4] https://www.theregister.com/special_features/blackhat_and_defcon
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/blackhatanddefcon&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZNVeBW8kPOtZripRgqpZwgAAAhY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/blackhatanddefcon&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZNVeBW8kPOtZripRgqpZwgAAAhY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://github.blog/2022-02-01-top-100-npm-package-maintainers-require-2fa-additional-security/
[8] https://github.blog/changelog/2022-11-01-high-impact-package-maintainers-now-require-2fa/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/blackhatanddefcon&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZNVeBW8kPOtZripRgqpZwgAAAhY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2022/05/05/github_2fa_mandatory_2023/
[11] https://www.theregister.com/2023/03/09/github_2fa_requirement/
[12] https://www.theregister.com/2022/05/05/github_2fa_mandatory_2023/
[13] https://www.theregister.com/2023/03/09/github_2fa_requirement/
[14] https://www.theregister.com/2022/08/16/rubygems_package_registry_mfa/
[15] https://www.theregister.com/2023/08/07/black_hat_tesla_hackers/
[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/blackhatanddefcon&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZNVeBW8kPOtZripRgqpZwgAAAhY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[17] https://whitepapers.theregister.com/
Ah Github...
Those who wanted me to use 2FA with a no longer functional email and refused to let me log-in and change it because the old email was no longer functional.
2FA connecting anything to something as insecure as mobile phones is a joke. I wish browsers would just use my SSH public key and be done with it when logging onto sites.
I also think central certificate authorities are a stone-age concept and am embarrassed that we haven't done better.
Everything is wrong with the web at this point.
You complain about the insecurity of mobile phones and then want to use a solution involving browsers which are far far less secure than phones?
For all the security issues regularly fixed in phones the number of actual exploits against them is pretty low - they are almost always targeted attacks or it is some Android app no one has ever heard of that affected a few thousand people in China. There has never been some sort of mass exploit on a phone affecting millions of people even one time, but that's happened with PCs countless times. So unless you are the type of person who would be chosen for a targeted attack on a phone, using an app on your phone (NOT SMS!) as the second factor is quite reasonable. It requires someone be in possession of your phone and be able to unlock it, so even if the 2FA is to a website you're opening in the phone's browser it is secure enough that real world exploit is quite unlikely.
If you want greater security than that use a separate 2FA device - which could be a second phone with no/minimal connectivity that is used only for 2FA and absolutely nothing else.
I suppose the main issue that I have with the way 2FA is generally implemented is that they all require access to largely the same thing. Either my phone (for a text message) or an email account. If I lose access to one of them, I'm pretty stuffed for all accounts that require that they are available. I consider that a single point (or 2 points) of failure. If my email account gets targeted and I lose access, I potentially lose access to everything else.
That's not a very comforting situation. Whenever another website starts requiring me to enable 2FA, I feel more vulnerable, not less.
Meanwhile...
on the rare occasion when Gmail requires me to do my 2FA thing, the "remember me on this device" box is checked by default...