Later this month, people who use GitHub may find themselves suddenly getting an error message while trying to authenticate against the GitHub API or perform actions on a GitHub repository with a username and password. The reason for this is the removal of this authentication option by GitHub, with a few ‘brown-out’ periods involving the rejection of passwords to give people warning of this fact.
This change was originally announced by GitHub in November of 2019, had a deprecation timeline assigned in February of 2020 and another blog update in July repeating the information. As noted there, only GitHub Enterprise Server remains unaffected for now. For everyone else, as of November 13th, 2020, in order to use GitHub services, the use of an OAuth token, personal token or SSH key is required.
While this is likely to affect a fair number of people who are using GitHub’s REST API and repositories, perhaps the more interesting question here is whether this is merely the beginning of a larger transformation away from username and password logins in services.
First of all, the good news is that dealing with this change isn’t super-complicated, and if reading GitHub’s blog posts has filled you with confusion and various levels of existential dread, here’s an easy way to fix it with minimal changes if you’re used to hammering in your credentials on the command line with the git client:
That’s it. If you already have an SSH certificate installed on your system, make sure to copy the public key into your GitHub profile. After this you can either clone your repositories anew with more SSH flavor, or change the git remote URL from HTTPS into its SSH equivalent.
Doing this requires opening the .git/config file in your local repository’s root folder in your favorite text editor (like Vim) and changing the remote’s URL. Simply change ‘https’ to ‘ssh’, and append ‘git@’ before the host name so that e.g. https://github.com/Foo/Bar.git becomes ssh://email@example.com/Foo/Bar.git.
Congratulations, you should now be able to use your SSH key to push, pull, fetch, rebase, squash and all those other naughty things with your remote repositories just like before. If you get weird SSH errors, it might be that you have the wrong permissions set on your ~/.ssh folder. Otherwise, enjoy not typing your username and password (or access token) any more every single time.
According to GitHub, the reason for this change is to increase security. Instead of passwords, they offer the use of personal access tokens (PATs) when using the REST API or accessing git repositories via HTTPS. The idea is that PATs can be created for specific services and individuals, to limit and grant certain rights. The resulting token is however a long string that you aren’t just going to remember and type in, which makes a password manager essential.
It is telling that none of this applies to logging into the GitHub website itself. There you can still use your username and password as before, possibly in addition to two-factor authentication (2FA) if you weren’t using it already. Here, the second factor in 2FA can be a code sent in a text message or mobile app, or something like WebAuthentication (FIDO2), with all the potential gotchas when using biometrics.
For those of us who were already using SSH with our GitHub repository queries, this means that essentially nothing changes. The use of access tokens should also come as no surprise to anyone who has integrated a CI system or similar with GitHub. It does however lead one to ask the question of what the point of GitHub’s change is if it only makes a few DevOps scurry around to update services (and fix the few that do fall over). Is anyone really trying to get rid of passwords?
As anyone who has ever managed a large, multi-user system at a university or large business knows, user account management is essential. Ideally you want to keep every user (whether a person, shell script or manager) in their own little permission zone. This is where GitHub’s announcement is perhaps the most puzzling. As noted by commenters over at Hacker News on the announcement, it would have made more sense to have expanded the access tokens to make more fine-grained and per-project roles.
Whether or not passwords are actually problematic seems to mostly depend on who you ask. If it’s a study commissioned by a company that sells alternatives to password-based logins, or the company behind Windows Hello, it’s the most insecure thing ever. However, as mentioned earlier, there are significant issues with these alternatives, especially biometrics.
In user authentication, identification can take place using something you have, something you are, and something you know. Biometrics is the practice of scanning a part of a person’s body and comparing it with previously stored data. This is public data which is becoming increasingly easier to copy and reproduce to fool biometric sensors. And of course if your biometric data falls into the hands of bad actors you can never change it.
Something which one has (wallet, credit card, hardware token) is easily stolen or lost. This is why such tokens are inevitably unlocked with a password, in the form of a personal identification number (PIN), which is awkwardly danced around as being a password, even though as a thing that ‘someone knows’ it is totally a password.
Things that people know are pretty amazing, because the only ways that they can be compromised are by forgetting them or by having someone record them using keyloggers, compromised ATMs, etc. This is demonstrated by the inability of US federal departments to force their way into password-secured iPhones. With the use of facial recognition all it takes is holding the phone up to the person’s face in order to unlock it, something which might even be legal for fingerprints. In some cases a photograph of the person suffices.
Realistically, the nice thing about GitHub’s change seems to be that it forces more people to finally toss out or rewrite those old scripts and forgotten-but-still-active Java back-end services that have username and password credentials hard-coded in them. Having them use SSH (conceivably using ssh-agent or GPG agent) eases maintenance and should improve security. Even if one just uses git repositories from the command line and doesn’t bother with a password manager, switching to SSH means less typing.
As an authentication mechanism, SSH provides two-factor authentication in the form of something you have (the secret key) and something you know (the key phrase). Its benefits are acknowledged by GitLab as well, who as of August 15th this year are no longer offering multi-factor resets for free user accounts. If one has an SSH key registered with the account, one can use SSH authentication to recover the account in cases where all of the other authentication methods have become unavailable.
Because of the power of keeping authentication information safely stored in our squishy, organic brains, all authentication methods seem to lead back to a form of passwords at some point. Even ‘password-less’ authentication tokens require a passcode (PIN), which one has to remember. The same is true for credit cards, debit cards, online banking accounts, SIM cards, password managers and so on.
On last count, I have to remember the PIN codes for multiple SIM cards, debit cards, credit cards, online banking apps, and one password manager for nearly a dozen total. Guess where these PIN codes end up? That’s correct, in the password manager, because remembering a random string of numbers is tricky, but remembering a dozen of them is a borderline nightmare scenario. Was it 7634 for that one debit card, or 7643? Or was that for the second credit card? Even Elliot Williams’ brain-based hashing system for PINs lets him write the public key on the card but it still demands that he remember the private key (and how to hash them in his head).
Perhaps that’s the appeal of biometrics: to have something that just is, with nothing to remember or some physical item to keep track of. Yet biometrics is the cryptology equivalent of printing your SSH private key on your forehead (or fingertips).
At the end of the day, it seems that all authentication roads end up leading to password managers and SSH keys.