Whether you're just getting started on GitHub or you're already a prominent open source contributor, you should take steps to ensure your account is protected against unauthorized access. Your account needn't be full of precious source code to be an attractive target; this is a common misconception. While it's true that some accounts are targeted specifically for the content they own or have access to, even an account with no content can still be a valuable thing to those with bad intentions.
Let's say, for example, an individual is looking to spread spam. In order to get their message out, spammers need accounts to proliferate it. GitHub's spam-fighting team are experts at finding these folks, so spammers need a lot of accounts if they want to have any chance at a meaningful outcome. Creating all these accounts can take a great deal of effort, however. We're always on the lookout for questionable patterns of activity that reveal their intended use. We find and hide these accounts with impressive speed, so spammers have to constantly find new ways of creating accounts that appear to be legitimate. This is hard to do at scale, which is why accounts owned by even the most casual of users catch their interest: at some point it becomes easier to take legitimate accounts from everyday users than it is to create an account that looks legitimate. In this way, an account used solely for writing fan fiction is of the same value to these folks as that of a user working with state secrets (until they found what that account contained, that is).
The first step to securing your account is to ensure you're using a strong password. This likely won't be news to many of you, but we just as likely all have a different idea of what constitutes a "strong" password. For those of you that haven't seen it, give our guide on this topic a read-through. There are two key take-aways I'd hope everyone gets from it:
All your online accounts should have a unique password. By using the same email/username and password combination for everything, it only takes one compromised service to put all of your accounts in jeopardy. It's common for stolen login information to be sold or shared publicly and bad actors will try re-using this on popular platforms (like GitHub) to see if it can be used to compromise other accounts. Don't make this easy for them: give all your accounts a password you've never used anywhere else.
As noted in the guide I provided a link to above, there are a number of ways to help make a hard to guess password easier to remember. For many, the best solution will likely be a password manager like 1Password or LastPass. These programs make generating strong passwords as simple as can be and can help you avoid falling back on predictable patterns or common word and number combinations. A password manager is only as secure as the password you use to secure it, so you'll want to be sure to apply the same principles here: make your master password unique and hard to guess. Using a mnemonic is a great way to avoid avoid forgetting the password you create for this.
Even if you don't know it by name, two-factor authentication is likely something you've used already. Much like the name would indicate, this feature adds a second layer of protection against unauthorized access. Often explained as being "something you know" and "something you have," the principles on which two-factor authentication are based are ones you've undoubtedly had experience with. When using an ATM, for example, you're essentially authenticating this way: your bank card being the "something you have" and your PIN the "something you know." Without both of these things, you wouldn't be able to withdraw any cash. When enabled on your GitHub account, the "something you know" is your account's password and the "something you have" is — in most cases — a mobile phone. Much like leaving your bank card at home, finding yourself without your phone will make accessing your GitHub account very difficult when two-factor authentication is enabled.
Every service that offers two-factor authentication may choose to implement it a little differently. On GitHub, you can choose to enable two-factor authentication using one of two methods: either by text message (SMS) or through the use of a special application on your mobile phone (or another device) that generates codes valid for a very short window of time — these are referred to as TOTP applications.
When authenticating via SMS, GitHub will generate an authentication code for you every time you provide a valid password at login. That code is then sent to the phone number associated with your account; providing it when prompted will complete the sign-in process, allowing you to access the account and its content.
Both methods of authentication have their own advantages and disadvantages. When using SMS, you'll need access to a cellular network in order to be able to receive the codes we send. If you're traveling out of the country and have no cellular coverage, this could prevent you from being able to access your account. Similarly, if you change your phone number and forget to update your account's settings, you'll have lost that account and its content.
SMS-based authentication is less secure than using a TOTP application (which you'll read about next). A determined attacker can exploit the fact that these codes are sent to your phone number and — with some craftiness and just a little information about you — intercept them.
Learn more about enabling SMS-based authentication for your GitHub account here.
Authentication with a TOTP application is a little different. Rather than us telling you what the authentication code is, the TOTP application you configured for use with the account will do this. The way you provide this code to access your account works the same way.
Using a TOTP application like Authy, Duo, Google Authenticator, or one of the many others available is the more secure method of the two. The downside to this method is that it can increase your risk of losing access to your own account. Remember: with this method you're essentially pairing your account with a device, rather than a phone number. With that in mind, losing the device can — and, in many cases, does — result in losing access to the account associated with it. In the interest of security, some TOTP applications (like the ever-popular Google Authenticator) don't create a backup of the secret used to generate your account's authentication codes. If you regularly upgrade your phone, that means you'll need to take extra care to ensure you have a fallback authentication method configured, or else you'll be unable to access your account to configure your new device and will have lost any content your account contains.
If you're interested in configuring two-factor authentication using a TOTP application, we have a guide that can walk you through this here.
Working in Support at GitHub, I get emails from dozens of folks every day that can't access their account due to two-factor authentication: phones get stolen, numbers get changed, and devices get erased unexpectedly. To make sure these events don't lead to the loss of your account (and everything it contains), it's essential to ensure some fallback options are configured. GitHub offers quite a few different methods you can use to prove your identity as the account owner, should your phone number or TOTP application no longer be accessible to you.
A set of recovery codes will be generated for you when you enable two-factor authentication. These codes are each valid for a single use and are hands-down the quickest way to regain access to your account, should you ever lose access to your primary method of authentication. I can't overstate the importance of ensuring these codes are not only kept safe from prying eyes, but also accessible to you. Computers are neither impenetrable nor infallible: print these codes out and store them in a place they won't be found by others or forgotten about. Remember to do this every time you enable two-factor authentication; these codes are invalidated any time you disable two-factor authentication, so you'll want to be sure you've got a copy of the codes most recently generated.
If you've already enabled two-factor authentication and aren't sure where your codes are, please take a break from reading this article and go download a new set now.
A fallback number
If you have a second phone number or your primary authentication method uses a TOTP application, adding a fallback number to your account may be worth consideration. Keep in mind that your account is only as secure as the weakest method you've enabled, however. Even if you normally authenticate with a TOTP application, configuring a fallback number would expose you to the risks SMS-based authentication carries with it. Should you need it, we have a guide that can walk you through configuring a fallback number here.
FIDO U2F Security keys
These are physical security keys that you can associate with your account and are the most secure method of authentication available. It's not currently possible to make this your primary method of authentication, however, as there's currently a limited number of browsers that support their use. If you're a Chrome user (or there's an extension available for your browser of choice), you might consider purchasing one of these keys and adding it to your account. This method of authentication may be of particular interest to users working in environments where the use of mobile phones is prohibited. At this point, I doubt it comes as any surprise we have a guide for adding these keys to your account; you can find that here.
Recover Accounts Elsewhere
The most novel form of authentication we offer is Recover Accounts Elsewhere, which allows you to use your Facebook account to prove your identity as the owner of your GitHub account. While I would recommend enabling this, authenticating this way requires you to contact GitHub Support. With that in mind, regaining access to your account this way will invariably take more time than the self-serve methods noted above. While we're more than happy to help you regain access to your account using this method, I'd recommend only authenticating this way if the other methods are unavailable to you. Configuring this is a breeze and — you guessed it — we have a guide available here.
While not a method of authentication I'd encourage you to rely on by any means, in limited circumstances GitHub Support may be able to help you regain access to your account using an SSH key if no other method is available to you. We believe that two-factor authentication is most secure when humans aren't involved in its operation, so this is only a method we entertain as a last resort and we can't guarantee it will always be something we support. That said, it may be worth adding an SSH key to your account so you have this option in your back pocket, should you ever need it. The fine folks on our Documentation team wrote a guide that makes generating and adding a key to your account a snap. That guide can be found here.
Should none of your configured authentication methods be available to you, GitHub Support will not be able to help you regain access to your account. In an effort to ensure we don't undermine the additional security two-factor authentication provides, we will refuse to accept credit card information, government-issued identification, social verification, or anything not explicitly mentioned here as a substitute.
Securing your account
Now that you've given this a read-through, take a moment to apply some of these suggestions to your account. Want to set a stronger password for your GitHub account? Those settings can be found here:
You can take things a step further and add two-factor authentication to your account:
If you have questions about the concepts or methods mentioned here, don't hesitate to share them in the comments below. If you have security-related questions specific to your account, it may be better to reach out to GitHub Support with those directly using our contact form:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.