Just so folks know, you can still use personal access tokens, which basically work as per-application passwords. For someone just getting started with git, I'd recommend they go to https://github.com/settings/tokens, generate a token, and then they can just use that as their password when running `git clone`.
This will certainly be a little more difficult for newcomers, and not very discoverable, but it is there.
Right, but this is also what makes me skeptical of the whole thing. I now have a Personal Access Token saved in my password manager. When I’m in a disposable VM, and git asks for a password (because it’s a fresh, disposable VM), I copy the personal access token out of my password manager, instead of copying my Github password out of my password manager.
Okay, no big deal, I just have to spend an extra second searching for the copy password icon, since it’s not in the same place as every other account password—but did this really improve my security at all? It’s just a different password.
> Tokens offer a number of security benefits over password-based authentication:
> - Unique – tokens are specific to GitHub and can be generated per use or per device
> - Revocable – tokens can can be individually revoked at any time without needing to update unaffected credentials
> - Limited – tokens can be narrowly scoped to allow only the access necessary for the use case
> - Random – tokens are not subject to the types of dictionary or brute force attempts that simpler passwords that you need to remember or enter regularly might be
I pretty much do the same thing, I just copy-and-paste a PAT from my password manager when I need it on VMs. The big benefit to us is that PATs are "limited", and mine only has Git repo access, so unlike my password, it can't:
- Delete repos
- Edit my GitHub organization
- Share my private repos with other users
- Add/remove SSH keys from my account
There's always the chance that a software you install on your VM would contain a keylogger (e.g. NPM/PyPI malicious libraries), so limiting the damage that your credentials can do is always a good thing.
In many cases, none of these makes a difference at all. You may have 3 apps that need the most important permission (so what if it has unnecessary access to gists, when it has and needs full access to private repos) that you use on a single computer with a password manager. Either way, you need to reset the password/key if it becomes compromised.
Still, it's good to be in the habit of doing this, because sometimes you do need it.
I would guess that "in my password manager" immediately puts you into the minority of GitHub users. (Maybe not the minority of power users or high-profile software maintainers, to be fair, but they care about security for the site in general.)
So maybe it didn't improve your security, if you were already letting your password manager generate distinct passwords, but it almost certainly improves the median user's security, who has come up with a weak password they think is strong, and may well use that password on multiple websites.
Generating the accout password instead of allowing a user-supplied password would also work here (and incentivize the use of password managers, if enough websites did it), but I would guess getting people onto SSH keys is useful for them in general - e.g., it allows them to make 2FA or CAPTCHAs mandatory for use of high-abuse-potential features like CI or Codespaces.
You're right, of course—I just resent being punished for other people's bad password choices. I wish they would turn it off by default (including changing existing accounts) and bury a checkbox deep in settings somewhere to turn it back on. Enabling the checkbox could even require that you change your Github password to something auto-generated!
Access tokens can practice least privilege and be scoped to a limited set of actions on a single repo. Your user password has whatever privileges your user has on every repo you've been given access to.
Not just whatever repo permissions your user has, critically your password has permissions to access your user account, which can do things like granting permissions to others, or changing your own security credentials.
But you set permissions on it, right? I might be wrong but I believe the idea is that if you’re a maintainer on say Homebrew you can set up your VMs to not be able to commit towards that.
This will certainly be a little more difficult for newcomers, and not very discoverable, but it is there.