Passkeys are now available in public beta. Opting in lets you upgrade security keys to passkeys, and use those in place of both your password and your 2FA method.
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. In fact, passwords, which we all rely on, are the root cause of more than 80% of data breaches.
That’s why GitHub is committed to helping all developers employ strong account security while staying true to our promise of not compromising their user experience. We began this commitment with our 2FA initiative across GitHub. Today, we are furthering this work by ensuring seamless and secure access on GitHub.com with the public beta of passkey authentication.
Passkeys build on the work of traditional security keys by adding easier configuration and enhanced recoverability, giving you a secure, privacy-preserving, and easy-to-use method to protect your accounts while minimizing the risk of account lockouts. Unlike SMS and email , passkeys are unique per website, so they cannot be used to track a user’s activities across different sites. The best part is that passkeys bring us closer to realizing the vision of passwordless authentication—helping to eradicate password-based breaches altogether.
To use passkeys with your GitHub account, navigate to your ‘Settings’ sidebar, locate the ‘Feature Preview’ tab, and click ‘enable passkeys’. Once you’ve enabled passkeys, you’ll be able to upgrade eligible security keys to passkeys and register new passkeys.
Up-to-date devices support passkeys right out of the box we just need to ask you to set one up. If you’re in the feature preview, we’ll ask your browser during sign in if you’re able to set up a passkey. If so, and you haven’t already set up a passkey on that device, we’ll ask you to set one up. By registering durable, secure credentials across all your devices, we hope to prevent account lockouts due to device loss.
Passkeys on GitHub.com require user verification, meaning they count as two factors in one—something you are or know (your thumbprint, face, or knowledge of a PIN) and something you have (your physical security key or your device). Because of this strength of authentication, we don’t need your password to trust that it’s really you signing in. Thanks to expanded browser support, your browser’s autofill system can automatically suggest that you use your passkey to sign in, right from the login page. It’s a magical experience—check it out:
Even better, this experience isn’t limited just to users with 2FA enabled—all users can complete a sign in using just their passkey.
Passkeys aren’t just usable on the device they’re created on—they can be used across your devices too. A new experience, known as cross-device authentication, lets you use a passkey on your phone or tablet to sign in on your desktop, by verifying your phone’s presence. You can select a previously linked device or scan a QR code with your phone, complete the sign in there, and then you’re all signed in on your desktop. Because your phone or tablet must be physically close to your laptop or desktop, cross-device authentication retains the phishing-resistant promise of FIDO.
See it in action here:
In addition to cross-device usage, many passkeys can be synced across your devices, ensuring you’re never locked out of your account due to key loss. Depending on your passkey provider, your passkey can be synced across your devices automatically—so your iCloud account will sync passkeys from iOS to macOS, Google Password Manager syncs across your Android devices, and password managers like 1Password or Dashlane can sync passkeys across installations of their password managers across any device. Expanded sync support is a work in progress for OS and browser vendors, but the core sync engines are there now.
Not all passkeys sync across devices—in your user settings, we show a ‘synced’ label on the credentials that are reported as syncing. Depending on your risk model, unsynced keys may be what you prefer—the choice is yours when it comes to choosing your preferred passkey setup.
Those security keys on your account might just be waiting to be upgraded and realize their full potential. If your security key is capable of verifying your identity (for example, Touch ID, Windows Hello, Android thumbprints, or PIN-locked or biometric hardware keys), then it’s eligible to be upgraded. The next time you sign in with that security key, we’ll ask you if you want to upgrade it to a passkey, which will re-register it with your passkey provider. This re-registration ensures that your passkey is discoverable during authentication, and synced, if supported. Because passkeys are privacy preserving, you might have to trigger your passkey a few times during that upgrade flow so we can make sure we’re upgrading the right credential. Once you do, you’re all set for a passwordless experience.
We’re excited to continue to provide more flexibility, reliability, and security in the ways you can authenticate to GitHub. We’re looking forward to your feedback on passkeys—please drop us a note in our public discussion and let us know what you think! You can also see our documentation for more information.
We’ve dramatically increased 2FA adoption on GitHub as part of our responsibility to make the software ecosystem more secure. Read on to learn how we secured millions of developers and why we’re urging more organizations to join us in these efforts.
This blog post is an in-depth walkthrough on how we perform security research leveraging GitHub features, including code scanning, CodeQL, and Codespaces.
In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that allows a malicious app to gain arbitrary kernel code execution and root on an Android phone. I’ll show how this vulnerability can be exploited even when Memory Tagging Extension (MTE), a powerful mitigation, is enabled on the device.
Hirsch Singhal 
