GitHub Authentication
GitHub is a big website where you can store computer code. If you use it, you know what it is. Twice, Github have made wide moves to complicate, sorry, increase, their security.
Summary
Since 2021–2023 Github has raised authorisation requirements considerably
To use Github, you need a secure connection (HTTPS codes or SSH) and some website authorisation (e,g, TOTP, SMS, or both)
Github say, if there is a loss or breach, accounts will not be restored if security codes are lost
Github recommend having backup authorisation methods
I’m a mediocre developer and I upload from the commandline
Ok, you probably need to move to SSH upload (HTTPS is a mess of tokens that won’t move easily between computers and will anyway keep expiring).
As for the 2FA (or, as I call it, MPA), you’ll need to at least log SMS details i.e. a smartphone number. You could use a TOTP application, though you’ll have little need for it elsewhere. On Linux you’ll be out‐of‐repository—see TOTP Apps. I think mostly the choice will depend what system you use—most TOTP applications do not run on all major systems.
As for the we‐recommend‐but‐lord‐spare‐you‐if‐you‐don’t statement, I don’t find it very clear what Github means. Minimal case seems to be,
2FA to the webpage. Either SMS or TOTP app
Stash security codes on two devices, or in secure cloud storage.
However, Github seems to suggest they will be difficult about using the recovery codes. For a small scale developer, this means you need two devices equipped with MPA. That way, loose one and you still have the MPA access Github prefers. This is rough on the poor, but these kinds of people are—a second computer or smartphone will ease a rescue situation. On a smartphone, you could use the Github app instead of TOTP app, though likely it’s only purpose would be as emergency backup, not daily usage.
And finally, whatever vault or manager you dump the recovery details into, this needs to be on two devices, or located on secure cloud storage.
Where Github started
GitHub handled uploads to the site through the commandline. This process is tweaky to set up, but handled all issues of the web with a plain password logon. When I say issues, I mean the uploading of data to a code repository. For access to the website, you logged on with id and password. Two activities, not overly difficult.
But those days are gone. Github now requires a more secure uploading style, and more secure site logons. They want the connections protected, either with a secure web connection, or using SSH access. And for the website access they want multiple factor authentication.
Secure logons
Communication
Circa. 2021 GitHub sent emails about increased authentication requirements. Though unclear the upshot was… no longer would plain passwords work, the company and website were requiring secure logons. This was a big move. For many, it required refactoring their uploading style, installing new systems.
GitHub asked this because, the company says,
These [new] features make it more difficult for an attacker to take a password that’s been reused across multiple websites and use it to try to gain access to your GitHub account.
In other words, end users are using poor password security. I doubt this was of great issue to the users. I suspect if there was an issue, it may have caused breaches of security for Github as organisation.
Yo announce the new requirements, Github used a ‘brown‐out’ for two periods. A ‘brown‐out’ means to block plain password access but not permanently. I found this a scaled and communicative approach to the change in requirements, far more so than the behaviour of other companies.
Methods of securing upload connections
HTTPS/token,
You’re already using an https connection (probably)
Need a token of some kind, but only at one end
When you use GitHub you must enter tokens as you entered passwords (well, you can use credential helpers)
GitHub tokens expire after a year of non‐use
Much more secure than an open link
Not promising, not with certificate managers and token timeouts.
SSH,
You probably have the software
Need to set up keys at GitHub and on your home computer. Annoying, and maybe hard to share
Auto logon (you can set a password if you want)
Very secure
Not good for sharing.
As far as I know, whatever method you use, clone downloads, ‘issues’ and all the rest of the Github API will continue to function as usual. However, there may be problems with SSH and upload contributions. I’ve not tried.
Enabling HTTPS/Token
You probably have HTTPS connections already. Git uses HTTPS whenever it can. So you should be set up already. Try,
git remote -v
on a repository. Should come back with an HTTPS address. But to update GitHub access, you still have the token to consider.
There are twp possibilities for the tokens,
Personal access token
OAuth
Mention of OAuth tokens is a Red Herring. OAuth isn’t a token, it’s an authentication system. It’s used by web apps mainly, like Twitter and the like, to shunt your personal details and authorisations between organisations. In short, OAuth is mentioned because some users may have apps that want to access Github. But it is not something Joe Developer needs, so I’m not mentioning it again.
Personal access tokens are a few levels of extra authentication. First the ‘password’ is an automatically generated string of chars. It only works down an encrypted web link (‘https’). At the far end it is granted access only with prearranged permissions.
I havn’t spent any time here. Start with creating a personal access token. I went for SSH. If I try it, I’ll tell you.
Enabling SSH access
Generate key
Follow Github instructions, or do this, with your GitHub email address,
ssh-keygen -t ed25519 -C "your_email@example.com"
When it says ”Enter a file in which to save the key,” press Enter. When asked, ‘type in a passphrase’, type one in. Then,
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Add a new Key
Follow Github instructions, or open this in a text editor,
~/.ssh/id_ed25519.pub
Copy the contents. Go to your Github area,
Github > ProfilePhoto > Settings > (sidebar) SSH and GPG Keys > New SSH key
Add a title, paste in the key, submit.
Switch Remotes
List current remote on a repository,
git remote -v
Then change it to SSH form,
git remote set-url origin git@github.com:USERNAME/REPOSITORY.git
Test,
git remote -v
Try a push. Will not do anything if up to date, but tests the connection, authorisation, and passphrase are working,
git push origin master
Repeat for every repository, until you are dog‐tired.
Enabling site access using MPA
Communication
‘MPA’ meaning ’Two Factor Authentication’. Which means there must be at least two different forms of identification to access Github. Well, this is from the Github email,
GitHub strongly encourages the use of multiple second factor options. If you lose all of your second factors, recovery codes are the only way to access your account again. By saving your recovery codes, you’ll be able to regain access.
And,
You should set up at least two of these options, to ensure you always have access to your account.
and,
For security reasons, GitHub Support may not be able to restore access to accounts with 2FA enabled if you lose your 2FA credentials and lose access to your account recovery methods.
I read main authentication, perhaps two backup methods, and recovery codes. There may be 2FA, but I count 4 procedures. Multiple procedure authentication, MPA, and that’s what I’ll call it.
Multiple procedure authentication is primarily a administrative burden for the user.
Why is GitHub asking this?
For MPA Github explained their reasons like this,
Ensuring account security is a shared responsibility GitHub takes seriously. Strong authentication and the use of 2FA have been recognized as best practice for many years. We feel that GitHub has a duty to lead this push toward strong authentication as part of protecting the software supply chain.
This is somewhat unlike Github as an organisation. It’s as close to an non‐explanation as can be achieved. ‘Best practice’ it may be, but that’s a call to authority—facts, please. And it assumes strong authentication is a good thing. I’m sure, for some customers of Github, it is. But not for everybody—strong authentication has downsides also.
Methods to enable MPA for Githuub
TOTP
Means time‐based one‐time password. TOTP apps can generate these passwords and, if registered, Github recognise the passwords they generate
SMS
i.e. mobile phone verification
Heedless of Github documentation, these are the two main ways.
Then, from Github procedure pages,
Configuring additional authentication methods will help you gain access to your account in case you lose your device and don’t have your recovery codes.
These next two harden the connections from devices you own,
security keys
Contrary to Github statements, this isn’t a wide authentication option. It’s a way of securing (‘hardening’) browser access by allowing a website to verify the accessing device is the same that registered. It can use tokens or physical devices (like fingerprint scanners)
GitHub Mobile
Is an app for a mobile phone. If you were wondering, which I was
What this suggests in general is that you should have at least two devices with one of these two supplementary methods enabled. If one device is compromised, the other has a supplementary method enabled as well as overall methods.
Plus the recovery codes. These will be sent if you enable any of these methods.
TOTP apps
Note Github gives no information on what a TOTP app is. It’s one of those weird apps that don’t explain what they are for, do nothing themselves, seem to require fraught setup using QL code scanning and the like, then waft up magic codes that use a countdown timer like a bomb in an old spy movie. Oh, and when you are asked to install them, they never work anyway. Often, being asked to install one of these apps is a clear sign that authentication and registration has failed. Microsoft’s ‘Authenticator’ app is a good example.
GitHub offers no names of codebases, examples, or other help. Also/besides,
We recommend using cloud‐based TOTP apps.
There are a few TOTP apps. Most do not work across the major platforms. There are issues and advantages to all of them. To mention some names that will inevitably change over time,
Google Authenticator
Microsoft Authenticator
Sophos Authenticator
LastPass Authenticator
2FAS
or a hardware solution like the expensive,
Yubikey
Not simple.
SMS
This is a passcode call‐and‐response to a phone or other device that can receive text messages. Usually, and for Github, means a mobile phone. Same idea your bank likely uses. SMS is not encoded, and I’ve seen plenty of demonstration it can be intercepted in passage. I’ve never found any facts. However, the use of these codes likely depends on the usual security idea of many barriers. What is the chance someone gets hold of your mobile, or taps your connection, and is also interested in your Github account? That’s a large reduction in attack level. Or increase in security level.
The Github instructions on setting up a mobile number for your SMS are straightforward. What is not mentioned is that you’ll need to do email verification first, and complete a CAPTCHA—meaning one of those ‘tick the boxes’ web things. Otherwise, straightforward.
Security keys
Extra security added by tokens. WebAuthn, mainly. WebAuthn works through some browsers. It prevents phishing. It binds logon credentials to a browser’s origin. It uses public key encryption, the same kind of strong encryption that can be used over SSH. It requires, for the appropriate site, Javascript to be enabled. But, statement from a Mozilla blog,
However, authentication systems tend to rely pretty heavily on network effects: it’s not worth users enabling it unless a lot of sites use it and it’s not worth sites enabling it unless a lot of users are willing to sign up
A true statement, and not promising.
How to enable? And where?
On Windows and iOS 14.5+, the WebAuthn platform authenticator is registered at the operating system level. Users can enroll with one browser and login with any browser. If Auth0 detects that users have a device enrolled, they will get the option to authenticate with Face ID / Touch ID / Windows Hello. If they enrolled with that same device they’ll be able to authenticate. If not, it will fail, and they’ll need to use another authentication method.
Mac?
On Mac, the WebAuthn platform authenticator is registered at the browser system level. Users will be asked to enrol with WebAuthn in each browser they use. If Auth0 detects that the user has enrolled from Chrome on a Mac, they will get the option to authenticate with Touch ID when they login from Chrome on a Mac
Android?
On Android, only Chrome supports WebAuthn platform authenticators.
What about Linux? Of which there may be a disproportionate number of Github users?
Also in existence are ‘YubiKeys’ and similar, where the authorisation and software can be carried on a USB stick or other portable memory. And Auth0, a registrable website that can also provide security keys. As can, I read, Firebase, Cognito, and Frontegg. But the point with them all is that they are business management tools or development environments. Auth0 offers a free signup.
Github Mobile
Letter information,
The GitHub Mobile app on your phone can be used as a 2FA method. Enable it by installing the GitHub Mobile app for iOS or Android and signing in to your account.
I suppose if your day‐job involves Github then you might do this. I propose that not everyone uses Github like this, and if that is the case, this is a wasteful way of authorising. As a backup, it seems sometime unlikely—loosing a mobile phone is more likely than a desktop. But if breaches of an office system are the concern, this would be a choice.
The recovery codes
Will be supplied as soon as you enable an authorisation method Github approves of. You download them as a text file. It is recommended you save these in a secure place. Or places.
My experience
Practice
For the record, I enabled secure access for uploading. Could be a battle to upgrade, especially on the same computer, but I guess that’s ok.
For site access I started with SMS, which is only the same as using online access to a current account at a bank, or similar. Niggly, but that’s modern life.
For TOTP I started with an App called ‘Authy’. Authy was low on fear and could be run from a desktop. In 2024 Authy developers called ‘End of Life’ on the desktop version. It’s clear that TOTP authentication (‘Authenticator Apps’) favours using mobile phones. I suppose this is because they are a second device. Myself, I agree a second device may aid recovery in some circumstances. However, use of a mobile phone in particular offers little extra security to a source‐authenticating app. My mobile phone is at high risk of damage or loss, so use of my mobile is an increased risk of broken access to my work. I’d say a near‐requirement to use a mobile phone (or even second device) demonstrates a lack of understanding by the computer industry that borders on the elitist. Nonetheless, this seems to be the expected behaviour, so for TOTP I switched to using my mobile and 2FAS.
On Github help
My original post, from the time of secure access requirements, contained ruminations about why companies are behaving as they are about authorisation. This time, I’ll note that Github,
explanations
were, for both moves, murky in motive and poor on detail
handling
has been open and staged, in both cases, about what will happen
documentation
has not been not clear, at times, what is required and what is not. Has not been clear, at times, what approaches are possible. Has lacked pros and cons of approaches. Has lacked any generality of who would be best using what. Has confusing and muddled categorisation and placement of material
instructions
have been comprehensive and clear
Mixed reactions. In my case, the Github email thanked me about the new authentication procedures. It should apologise.
Alternatives
Join Gitlab. Though they’re probably little different in terms of authentication.
References
Secure Access
Original notice,
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
caching credentials,
https://docs.github.com/en/github/getting-started-with-github/caching-your-github-credentials-in-git
Personal access token documentation,
https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token
OAuth apps,
https://docs.github.com/en/github/authenticating-to-github/authorizing-oauth-apps
What you need to know about OAuth,
Setup SSH,
https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh
Switching remotes to HTTPS,
MPA
Github explaination of MPA, https://github.blog/2023-03-09-raising-the-bar-for-software-security-github-2fa-begins-march-13/
MPA instructions, https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication
The Authy website explains the scene in plain English.
Wikipedia generalities, TOTP authentication,
Wikipedia, list of TOTP applications,
https://en.wikipedia.org/wiki/Comparison_of_OTP_applications
Human description of WebAuthn. I like the ‘simple 8‐stage process’ statement,
WebAuthn overview,
https://stackoverflow.com/questions/57674215/how-to-implement-webauthn-in-an-android-app#57680198
Auth0, WebAuthn in practice, one biometric device only,
Technical but readable description,
https://blog.mozilla.org/en/mozilla/password-security-part-iv-webauthn/