GitHub will require all users who contribute code on the platform to enable two-factor authentication (2FA) as an additional protection measure on their accounts by the end of 2023.
Two-factor authentication increases the security of accounts by introducing an additional step in the login process that requires entering a one-time code.
For GitHub users, account takeovers can lead to the introduction of malicious code for supply chain attacks that, depending on the project’s popularity, may have a far-reaching impact.
Imposing 2FA as a mandatory measure for all GitHub accounts will make the platform a safer space where users can feel more confident about the quality of the code they download from repositories.
Earlier in the year, the software hosting and collaboration platform announced a similar decision that concerned active developers of high-impact projects with over a million downloads/week or over 500 dependents.
Once expanded to the entire user base, the new 2FA requirement will help secure the accounts of approximately 94 million users.
While GitHub had announced this decision previously, it has now shared more details about how it will implement the new measure.
Rolling out the 2FA requirement
GitHub will roll out mandatory 2FA on all GitHub accounts beginning in March 2023, pushing it at first to select groups of contributors.
The feature rollout will be evaluated before it’s scaled to larger groups, measuring onboarding rates, account lockout and recovery, and support ticket volumes.
GitHub says the pool of larger groups will be built using the following criteria:
- Users who published GitHub or OAuth apps or packages
- Users who created a release
- Users who are Enterprise and Organization administrators
- Users who contributed code to repositories deemed critical by npm, OpenSSF, PyPI, or RubyGems
- Users who contributed code to the approximate top four million public and private repositories
Those who receive advance notice to enable 2FA via email will be given a 45-day period to do it.
Upon reaching the deadline, the users will start seeing a prompt to enable 2FA on GitHub for another week, and if they fail to take action, they will be blocked from accessing GitHub features.
“This one-week snooze period only starts when you sign in after the deadline, so if you’re on vacation, don’t worry – you won’t come back locked out of GitHub.com,” clarifies the announcement.
Twenty-eight days after enabling 2FA, the users will undergo a mandatory check-up to confirm the new security setup is working as expected while allowing users to reconfigure their 2FA settings and recover any lost codes.
Comments
xafase - 1 year ago
2FA. The greatest waste of my time to cover for idiots that can't properly manage passwords.
NoneRain - 1 year ago
To not use MFA is idiotic m8, or do you trust so profoundly on service providers securing those hashes?
bantling - 1 year ago
Perhaps xafase is like me, and has the worlds most singularly unfreakin popular git hub account hosting code no one will ever give a flying crap about. Basically, github is just a backup in case my computer lights on fire.
For people like me, MFA is a waste of my time. I hope/assume that this waste of time only applies to logging in to the github website, not pushing code via an ssh key (no one seems to have clarified this is any article I've read).
If so, then it doesn't really affect me, as I will only login once or twice a year anyway. Just one more line to enter in my passwords file.
chadf - 1 year ago
If github was really serious about code security, they'd mandate that all commits were cryptography signed/verified. It doesn't matter much if commits in local/mirror repositories/workspaces get compromised before they are pushed to github (using MFA). The best point to "secure" code is the time of commit, when the window between edits and commits is the smallest. Not that there isn't a chance it couldn't be compromised there too, but at least less chance of so without being noticed by the person committing the changes.
And are they going to automatically invalidate any [long lived] access tokens which where created before MFA was enabled/used to create those tokens? Again, MFA doesn't help if tokens were created before it was locked down, possibly just lying in wait, ready to do harm after the site was *cough* secured.