2FA

3 strategies to expand your threat model and secure your supply chain

As GitHub’s Chief Security Officer and SVP of Engineering, one of the most common discussions I have with other engineering and security leaders is the state of supply chain security. We all know it’s been an interesting few years, and supply chain security has rocketed into the mainstream—but where should one start when it comes to securing the supply chain? There are many acronyms and security “solutions” out there. How can teams get the bigger security picture? I recently talked about this problem at the BlackHat CISO Summit and want to share a few prompts you can discuss with your teams and customers to broaden your perspective on supply chain security. These prompts can help open up your aperture for thinking about the breadth and complexity of supply chain security while realizing some quick wins that you can do today—without any extra tooling or purchases. Strategy #1: Understand and account for your build pipelines The SolarWinds incident was a watershed moment that woke the world up to the threat of supply chain attacks. It involved a sophisticated attack on various organizations and government agencies by exploiting vulnerabilities in SolarWinds’ Orion platform, a widely used network management software suite. This incident showed us that the pipelines we use to produce software applications are just as important to secure as the application code itself. Build systems are production systems, period. They are extensions of your production environment and must be protected with the same level of rigor as you protect your most sensitive operations. The problem is that many organizations don’t know the sprawl of their build systems and don’t treat the ones they know about as production systems. Ask yourself: what controls do you have in place for all your code and artifact systems? How many build systems do you have? How many tech stacks do you use? As we saw with SolarWinds, we need to understand exactly what inputs are coming into the software artifacts we’re producing and account for them in the build process. Strategy #2: Require users to use 2FA As an industry, we still need help with basic security hygiene and controls, like adopting 2FA. At GitHub, security starts with the developer, and as such, we now require 2FA for all code contributors on GitHub.com. Empowering developers to prevent open source ecosystem attacks by better securing their accounts from theft or takeover is one of the most critical steps we can take to secure the supply chain. We made this decision after rolling out the npm registry for high-impact package maintainers. By requiring 2FA on the accounts of code contributors, maintainers, and publishers, we’re working to address one of the top, long-standing security threats: phishing. While parts of the security industry love to focus on more exotic threats and more complex capabilities, the reality is we need to start with the basics. With 2FA, GitHub dramatically reduces the likelihood of account takeover of popular package maintainers on npm and GitHub.com contributors—and by extension, mitigates the risk to other developers who depend on that code. You should be using 2FA everywhere you can. We have resources that can help you easily set up 2FA for your account or require 2FA for your organization. This simple step will go a long way in preventing your accounts from being compromised […]

Read More

Passkeys are generally available

Passkeys are a new form of sign-in and phishing resistant credential that make it easier to protect your GitHub account by reducing use of passwords and other, more easily phishable authentication methods. Since the launch of passkeys in beta in July, tens of thousands of developers have adopted them. Now, all users on GitHub.com can use passkeys to protect their account. This continues our commitment to securing all contributors with 2FA by the end of 2023 and strengthening security across the platform—without compromising user experience. Read on to learn about how to enable passkeys on your GitHub account. And, for those of you also building authentication experiences, we share what we’ve learned about how to roll out and make passkeys easy to use to help you integrate this powerful new credential method more quickly in your service. Get started with passkeys To register one or more passkeys on your account, head to your account security settings and click “Add a passkey.” If you already have security keys set up, you might see an “Upgrade” option next to those, if they are usable as passkeys. For more details about upgrading security keys to passkeys, read the passkeys docs. What we’ve learned building support for passkeys Passkeys are a relatively new credential type, and we’ve learned a lot about how to make them easy to use for large communities. Here we’ll share some of what we learned, and how we responded to that feedback—to help other authentication teams looking to adopt passkeys into their product. Not every platform is passkey ready, but they can still be supported We found that Linux and Firefox users struggled to use passkeys, as those platforms don’t yet have strong support for passkeys. As a result, we decided to enable cross-device registration of passkeys. That means, you can register a passkey on your phone while you’re using your desktop. The passkey lives in the phone, but users can connect it to their desktop and set-up and authenticate through the desktop’s browser. This enables Linux and Firefox users to set up passkeys. At a technical level, this meant ignoring the results of the IsUserVerifyingPlatformAuthenticator API (IsUVPAA) call, and instead just relying on the presence of the webAuthN APIs. This meant that both hardware keys (which don’t cause the IsUVPAA check to return true) and cross-device usage could still be accessed even when the underlying combination of OS and browser didn’t result in IsUVPAA returning true. Make it easy to upgrade compatible security keys There are a lot of security keys already registered on GitHub.com, many of them hardware keys. We had predicted that most hardware key owners wouldn’t want to upgrade to a passkey, due to threat models and lack of sync support. But a lot of users opted to upgrade a compatible security key to a passkey. So, we invested in making it easier to do so. In the account security settings, a new “upgrade” arrow next to compatible security keys enables immediate upgrade. Note that not every compatible security key will have this button next to it, as we only started checking for compatibility in late February this year. We also learned that some browser, OS, and security key combinations don’t support the re-registration flow that we use for upgrades, and will error if GitHub attempts […]

Read More