Was GitHub's password authentication removal an overstep?

I can’t help but think GitHub went a little too far with its removal of password based authentication to its servers.

Until August 2021, you could perform a push to GitHub with little more than your username and password as credentials.

You can’t do that anymore. If you try, you’ll run into an error: ‘Support for password authentication was removed.’

Instead, if you want to push to GitHub, you must provide a personal access token or authenticate with some form of credentials manager. I think this is an overstep.

Selective security

The first rule of security is to only secure what needs to secured. The second rule of security is to never apply more layers of security than are necessary. The third rule of security is to allow the user to perform the task at hand without needlessly getting in their way.

GitHub’s removal of password authentication support violates all of these rules.

The vast majority or repositories on GitHub belong to recreational developers. These people create GitHub repositories because they are trying to learn Git, because they want to save the code they’ve written as they learn a new language, or because they are writing code for some side hustle they will likely never get off the ground. For these people, a simple username and an eight-character password is more than sufficient.

For more serious developers, the use of a strong password is more than sufficient as well. If a long password validates against a list of well-known character sequences, the chance of a hack is small.

Nevertheless, GitHub has decided that password authentication is no longer acceptable. Instead, a developer must generate a personal access token in GitHub.

For large enterprises, the user of personal access tokens make sense. But the choice to use tokens should be an option, not a requirement.

Unintended consequences

The generation of the GitHub token is not an onerous task. Unfortunately, the same can’t be said about remembering the token’s associated character sequence — and this long character sequence must be used to push code back to GitHub.

My guess is that small teams will share this long sequence of characters through email and write it into plain text files on the user’s machines. This creates a new threat vector that didn’t exist before. I’d even bet that many users embed their tokens inside the GitHub repository itself, where it is in plain sight for all to see.

The impossibility of memorizing this token may actually make a GitHub repository more likely to be hacked, especially for recreational users who are less diligent about token security.

Corporate due diligence

I get it. If a high-profile client’s code repository is hacked due to a weak password, it’s GitHub that gets egg on its face. With the new, enhanced security features, if such a situation arises, GitHub can attest that it did everything it could to secure the platform. If a hack occurs, the blame will be attributable to the user’s malfeasance.

Personally, I don’t think the recreational developer needs GitHub’s personal access token based security. It was a poor decision to remove GitHub’s support for password authentication. Working with GitHub becomes more difficult, and it’s much harder for beginners to get started with Git and GitHub.

Personal access tokens play an important role in managing an enterprise’s security. Making them a requirement is an overstep.