Why Use Two-Factor Authentication (2FA)?
While it's still relatively uncommon, data breaches do happen. In some cases, that can mean that the login credentials of user accounts on a given platform fall into the wrong hands. If you've never visited it before, checking your email address or addresses at Have I been Pwned can be a sobering experience. As lots of people reuse passwords and other credentials across a number of platforms, one breach can impact on any number of accounts.
So what happens if your email and password are leaked and used by a malicious actor? Under normal circumstances, this information would be enough for a third party to access any online accounts that use those login credentials. Two-factor authentication throws up an additional barrier to keep your accounts more secure.
If you've ever used online banking, you've very likely run into 2FA. The second 'factor' of authentication is an extra login requirement. This is quite often in the form of an SMS sent to your phone, or a code generated by an authenticator application. When you login to your account, you're not only required to enter your email and password, but also to enter a one-time access code.
If someone gained access to your email and password but 2FA had been set up, they still wouldn't be able to access your account without that additional code, giving you extra peace of mind.
While it's absolutely worth adding 2FA to your account, what happens if you change your phone number without updating your 2FA settings, or accidentally delete the application that generates your access codes?
The Case For Additional 2FA 'Fallbacks'
In the worst case scenario, losing access to your 2FA credentials can mean that you'll also lose access to the account you've added 2FA to.
This is because opting in to use 2FA requires the platform (in this case, GitHub) to verify account ownership with more than one factor of authentication. Waiving the requirement would, unfortunately, undermine the purpose of having set up 2FA in the first place -- namely, to ensure that email and password credentials aren't enough to verify account ownership.
This can leave you in a bind, where the very tools you've set up to protect your account, wind up costing you access to that same account.
Adding 2FA fallbacks is a remedy to that problem. As the name suggests, a 'fallback' is a different, additional method of authenticating if you lose access or run into issues with your primary 2FA method.
The Fallback Methods Available
At the time of writing, you can set a TOTP authenticator application or SMS (region allowing) as your primary method of two-factor authentication. Our help documentation includes a guide on configuring two-factor authentication that will get you started.
In addition to that primary means of authentication, you can then add one or more of the following fallback methods:
A backup SMS number, ideally sent to a different phone the one used for your primary 2FA method
Recovery codes (printed, downloaded as a text file, or copy-pasted into a safe location)
An Accounts Elsewhere recovery token, set up by associating your GitHub account with a different account, such as your Facebook profile
A physical U2F security key
While not an official or entirely dependable recovery mode, it's also occasionally possible to authenticate ownership via adding an SSH key to your account. However, this is not a recommended fallback so much as an additional potential recovery vector of last resort.
How Many Fallbacks to Add to Your Account
There's no right or wrong answer as to how many fallbacks to add to your 2FA setup. On the one hand, the more fallbacks you have at your disposal, the better protected you are against the failure or loss of one or more of them.
On the other hand, having more fallbacks can open the possibility of one or more them finding their way into the wrong hands.
It's a good idea to have at least one fallback set up, and adding more than one is often considered good practice. However, it's important to make sure that the location of your fallbacks is both safe and, ideally, distinct from the device you use to access to your account.
Let's say you decide to use SMS as your primary 2FA method for account authentication. You might then opt to use a set of recovery codes as your sole fallback.
The efficacy of that fallback will depend to a large extent on where those codes are stored.
On the one hand, if you store your recovery codes on the phone you use to login to your account and receive your primary 2FA method (SMS codes), you're at a considerable risk if you lose the phone.
On the other hand, if you primarily log in to GitHub via your laptop, have your codes sent to your phone as SMS messages, and have printed your recovery codes (or stored them in a password manager with cloud syncing capabilities), you'll have a much greater chance of being able to find and use your recovery options should you lose access to one or more of those devices.
In short, keeping your 2FA fallbacks in distinct, discrete locations will give you a higher chance of being able to access them. It's worth noting that keeping them in a secure place, such as an encrypted password manager application, will provide greater peace of mind than leaving a printout pinned to your desk, for instance.
Two-factor authentication undoubtedly provides a much needed additional layer of security for your GitHub account. While rare, breaches of account information have been known to happen on the web. However, with extra security comes the additional risk of losing access to your account.
Adding secure fallbacks to your 2FA setup, and keeping them in a safe, discrete, secure place can ensure that even in an emergency, you'll continue to enjoy access to your account without issues.
Configuring two-factor authentication: help documentation on getting 2FA set up for your account
Configuring two-factor authentication recovery methods: documentation on how to set up each of the recovery fallbacks discussed in this article
Have I Been Pwned: a useful resource for checking whether one or more of your email addresses has been involved in a credentials breach
... View more