Search the Community

Though technology has advanced significantly to combat the proliferation of sophisticated security threats, the reality is that preventing the next cyberattack depends on getting the security basics right, and efforts to secure the software ecosystem must protect the developers who design, build, and maintain the software we all depend on. As the home to the world’s largest developer community, GitHub is in a unique position to help improve the security of the software supply chain. In May 2022, we introduced an initiative to raise the bar for supply chain security by addressing the first link in that chain—the security of developers. Because strong multi-factor authentication remains one of the best defenses against account takeover and subsequent supply chain compromise, we set an ambitious goal to require users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023. What followed was a year’s worth of investments in research and design around the implementation of these requirements, to optimize for a seamless experience for developers, followed by a gradual rollout to ensure successful user onboarding as we continued to scale our requirements. While our efforts to ensure developers can be as secure as possible on GitHub.com don’t end here, today, we’re sharing the results of the first phase of our 2FA enrollment, with a call for more organizations to implement similar requirements across their own platforms. Let’s dive in. Results We’re proud of the initial achievements from the 2023 initiative, and the impact they’ll have on ensuring the software ecosystem is more secure. We saw: Dramatic increase in 2FA adoption on GitHub.com, focused on users who have the most critical impact on the software supply chain. Users adopting more secure means of 2FA, including passkeys. Net reduction in 2FA-related support ticket volume, something we credit to heavy up-front user research and design as well as customer support process improvements. Other organizations like RubyGems, PyPI, and AWS joined us in raising the bar for the entire software supply chain, proving that large increases in 2FA adoption aren’t an insurmountable challenge. 2FA adoption Since we began rolling out mandatory 2FA in March 2023, we’ve seen an opt-in rate of nearly 95% across code contributors who received the 2FA requirement in 2023, and enrollments continue to trickle in. Moreover, this has led to a 54% increase in 2FA adoption among all active contributors1 on GitHub.com. Stronger and more reliable authentication A key area of focus for this initiative was encouraging users to adopt more secure means of 2FA, especially passkeys which currently offer the strongest mix of security and usability. Since we released passkeys to public beta in July 2023, nearly 1.4 million passkeys have been registered on GitHub.com. Even more impressive, passkeys rapidly overtook other forms of Webauthn-backed 2FA in day-to-day usage. While we’re bullish on passkeys, it’s also important that GitHub continues to offer flexibility, reliability, and security in the ways developers around the world can authenticate to the platform, particularly for those who may not have access to such technology. We continue to support SMS as a 2FA option for those who may not be able to adopt other factors, but have intentionally made design choices in our 2FA onboarding workflows to encourage users to adopt more secure alternatives where possible. This work reduced the overall share of SMS as a second factor by almost 25% between early 2023 and early 2024. We see a lot of room ahead to continue driving passkey adoption, while also driving down use of less-secure factor types, and foresee a future where passkeys are the first choice for the majority of developers on the GitHub platform. Finally, as a result of our improved enrollment experience and passkey rollout, our data shows that it’s 47% more likely users will configure two or more forms of 2FA. Each additional factor makes it far less likely that a given user will lose all their factors and end up locked out, resulting in a smoother and more reliable user experience. User experience and support Knowing we needed to help developers employ strong account security while maintaining our promise of a seamless user experience, we invested in a number of improvements including refreshed 2FA onboarding flows, adding GitHub Mobile 2FA, and more user options in terms of primary 2FA factors. While one would reasonably expect an increase in 2FA-related support tickets as the relative usage increased on the platform, we saw the opposite. Because of the significant investments in user experience and design ahead of the rollout, we saw a one-third reduction in 2FA-related support tickets. Further, additional internal workflow optimization and automation for GitHub Support teams led to a 54% reduction in 2FA account recovery support tickets that require significant human intervention. Today, more than 75% of account recovery tickets come through the in-product workflow, which collects recovery details from users and automatically checks for risk factors, as well as scenarios we know are safe (like doing account recovery while you’re still signed in). This data collection and vetting dramatically reduces the time it takes for GitHub Support teams to review these recovery attempts, allowing locked out users to safely get back to their accounts faster than ever and enabling GitHub to scale 2FA enrollment to millions of users. We also introduced a 2FA verification checkup that occurs 28 days after 2FA setup, to ensure users have an opportunity to verify their configuration. This checkup was a fail-safe that helped 25% of users successfully reconfigure their accounts if they made a mistake or lost a factor, thereby avoiding account lockout for the user and significantly reducing account recovery support volume for GitHub. Ecosystem impact While our primary focus was to secure the developers on GitHub.com, we have also been intentionally transparent with our approach to the rollout to inspire more organizations to take up the call after GitHub and npm to require their own 2FA requirements. Every user account with 2FA successfully enabled is one fewer vector for attackers to compromise organizations or important open source software. Over the last two years, we’ve been encouraged to see RubyGems, PyPI, and AWS join our efforts to drive increased usage of 2FA to secure our shared ecosystem and software supply chain. Looking forward Now that it’s 2024, you might be asking, “Why didn’t I get a 2FA requirement?” While we’re ecstatic at the progress we made in 2023 to enroll millions of developers in 2FA, the job of securing the software supply chain and the developers responsible for it doesn’t end. Our initial work prioritized distinct user groups based on the impact of their user privileges or specific actions they took. Protecting Accounts Without 2FA Those who are not required to enable 2FA still benefit from layered protections such as verified devices and compromised password prevention. There is also still important industry-wide work ahead to support users that may not have access to a phone or control over the software of the computer they use to adopt 2FA. As a global platform, we believe that everyone should have access to tools that make software development easier and more secure, and our efforts to enforce strong authentication for as many developers as possible is ongoing. We’ll continue to find solutions to protect developers, the projects they’re working on, and the communities they participate in, working hard to take a balanced approach that greatly improves the security of the entire software supply chain without restricting those with different setups or environments around the world. Looking ahead, we’re evaluating how we can require even more GitHub.com users to enroll in 2FA during 2024, while continuing to monitor and improve the user experience. We’re investigating additional account security features, such as session and token binding, that will enable developers and their organizations to better manage the risk of account compromise, with or without 2FA. We also want to continue to drive adoption of the most secure factors available to developers on the platform, such as passkeys or security keys, and help developers “move up” to more secure authenticator types. Throughout this, making security easy and effective remains a top priority—after all, security that isn’t usable isn’t security at all. A call to action We all have a role to play in securing the software ecosystem, and platforms must commit to being both a responsible consumer of software and contributor back to it. GitHub chose to take on 2FA at scale because we believe it’s the right thing to do to protect the entire ecosystem and we believe it’s vital that other organizations join us. Our work here shows that it’s possible to raise the bar for security significantly without negatively impacting users’ experiences. We encourage other organizations to strongly consider making 2FA requirements on their own platforms where possible. If you’d like to learn more about how we rolled out 2FA for millions of developers, look forward to a follow-up post that takes a deeper dive into our work in the coming weeks. If you’d like to join us in this effort, enable 2FA on your own account, adopt passkeys, or require 2FA for your organization. Note: If you or your organization are implementing internal 2FA-related policy, please note that our requirements are not designed to cover all GitHub.com users. Read more about our current enrollment criteria here and consider requiring 2FA for your organization. Want to learn more about how GitHub can help you easily secure your code? At GitHub Universe 2024, we’ll explore cutting-edge research and best practices in developer-first security—empowering you to ship secure code fast. Our Super Early Bird sale ends soon! Buy your tickets now. Note that all active contributors includes users that made contributions, which didn’t specifically qualify them for 2FA requirements, such as issue comments. ↩

Kindly, tell me if can we implement the 2fa while my pipeline runs and log in to my server. Currently, it login with a username/password to my server. Now, I want an extra layer of 2FA. So, is there any mechanism to do this? Kindly reply to me ASAP. Thanks,

Learn the key differences between multi-factor authentication (MFA) and two-factor authentication (2FA) and find out which one is best for your business needs.View the full article

A company that handles SMS text message routing has secured one of its internal databases after discovering it could be accessed with nothing more than an internet connection and a public IP address. The routing service handled time-sensitive messages used for one-time passcodes and reset links for two-factor authentication services (2FA). 2FA provides a secure method of identity and access management that is more secure than using just a password, and can help protect vulnerable networks. Sealing the leak The vulnerable database was discovered by good samaritan Anurag Sen, who is a security expert and researcher. Sen, upon discovering the database and being unable to trace its owner, reported the database to TechCrunch. TechCrunch managed to identify a number of corresponding email addresses and passwords within the database that contained information hinting to the leaking database’s owner. The database belonged to YX International, a company that specializes in cellular networks, and provides critical routing services for time-sensitive messages. YX International took down the database shortly after being notified, and then released a statement that the vulnerability had been fixed. The database was responsible for handling one-time access codes for Facebook, Google and TikTok accounts, and there is no evidence that any data was stolen because the database did not retain access logs. Evidence within the database suggested that it has been active since July 2023, but YX International did not confirm how long the database had been left unsecured. Sen told TechCrunch that the database held password reset links, alongside the one time access codes, for tech and social media giants such as Google and WhatsApp. While one-time access codes provide a superior level of security over just using a password, they are not as secure as dedicated 2FA and multi-factor authentication applications. More from TechRadar Pro 3D printer users say their devices were hacked to warn of a security flawThese are the best password managers aroundLazarus hackers return and hijack a Windows security flaw View the full article

Multifactor authentication (MFA) is becoming increasingly standard within software development organizations, with GitHub recently announcing that two-factor authentication (2FA) will be mandatory for all code contributors by the end of 2023. This is a smart move. In recent years, bad actors have frequently initiated attacks by accessing source code through the use of stolen developer […] The post What GitHub’s 2FA Mandate Means for Devs Everywhere appeared first on DevOps.com. View the full article