Action needed by GitHub Connect customers using GHES 3.1 and older to adopt new authentication token format updates
Upgrade to GHES 3.2 or newer by June 3rd to continue using GitHub Connect.
The software supply chain starts with the developer. Developer accounts are frequent targets for social engineering and account takeover, and protecting developers from these types of attacks is the first and most critical step toward securing the supply chain. GitHub has a long history of protecting developers through efforts including seeking and invalidating known-compromised user passwords, offering robust WebAuthn security key support, and enrolling all npm publishers in enhanced login verification. Today, as part of a platform-wide effort to secure the software ecosystem through improving account security, we’re announcing that GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.
GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.
GitHub is committed to making sure that strong account security doesn’t come at the expense of a great experience for developers, and our end of 2023 target gives us the opportunity to optimize for this. As standards evolve, we’ll continue to actively explore new ways of securely authenticating users, including passwordless authentication. Developers everywhere can expect more options for authentication and account recovery, along with improvements that help prevent and recover from account compromise.
In November 2021, GitHub committed to new investments in npm account security in the wake of npm package takeovers resulting from the compromise of developer accounts without 2FA enabled. We continue to introduce improvements to npm account security, and are equally committed to securing the accounts of developers using GitHub.
Most security breaches are not the product of exotic zero-day attacks, but rather involve lower-cost attacks like social engineering, credential theft or leakage, and other avenues that provide attackers with a broad range of access to victim accounts and the resources they have access to. Compromised accounts can be used to steal private code or push malicious changes to that code. This places not only the individuals and organizations associated with the compromised accounts at risk, but also any users of the affected code. The potential for downstream impact to the broader software ecosystem and supply chain as a result is substantial.
The best defense against this is moving beyond basic password-based authentication. We have already taken steps in this direction by deprecating basic authentication for git operations and our API and requiring email based device verification, in addition to a username and password. 2FA is a powerful next line of defense; however, despite demonstrated success, 2FA adoption across the software ecosystem remains low overall. Today, only approximately 16.5% of active GitHub users and 6.44% of npm users use one or more forms of 2FA.
At GitHub, we believe that our unique position as the home for all developers means that we have both an opportunity and a responsibility to raise the bar for security across the software development ecosystem. While we are investing deeply across our platform and the broader industry to improve the overall security of the software supply chain, the value of that investment is fundamentally limited if we do not address the ongoing risk of account compromise. Our response to this challenge continues today with our commitment to drive improved supply chain security through safe practices for individual developers.
Want to get a head start? We recently launched 2FA for GitHub Mobile on iOS and Android! Click here to learn how to configure GitHub Mobile 2FA today. To configure Mobile 2FA, you’ll need to have at least one other form of 2FA enabled. Expand the drop-down below to learn more.
You can get started here. To support adoption of security keys we’ve distributed security keys, like YubiKey, to critical open source project maintainers and stocked security keys in the GitHub Shop. SoloKeys or Titan Security Keys are also great options.
Don’t forget to save your recovery codes and configure one or more account recovery methods as well!
GitHub.com organization and enterprise owners can also require 2FA for members of their organizations and enterprises. Note that organization and enterprise members and owners who do not use 2FA will be removed from the organization or enterprise when these settings are enabled.
Over the coming months, we’ll share more details and timelines for future 2FA requirements for GitHub.com users. While we strongly believe 2FA for active contributors (for example, those who commit code, open or merge pull requests, use Actions, or publish packages) is the right thing to do, we also want to ensure a smooth and accessible experience, so look out for future improvements and new features designed to help you secure and recover your accounts.