Head First Git

[paul nisset]

Hi,
Last year GitHub forced everyone to use what they call Tokens to access their own repositories. To me, it seems like all they did was force me to update my own Github repository password with a very long one that Github generated . It being long and unmemorizable doesn't make it a token .It just makes it a long unmemorizable password that now has to copied and stored everywhere I use Github.

The outcome of this forced password  change is now there is a physical copy of this password on every computer I use to access my Github repositories. This is not more secure from my perspective.

I'm still prompted to manually enter (copy and paste) this long password whenever I need to access a Repository using Git's own command line tools.

What I thought was extra special was that ,in order to implement this forced change, I had to log into Github itself with  my own password.

Did I miss something with this process or was this as stupid as it appears to be?

thanks,
Paul

[Raju Gandhi]

Hi Paul,

Thanks for the question. You are right—GitHub institutionalized the use of Personal Access Tokens (or just tokens) to be able to pull and push to GitHub. There's two things to remember here:

- You still have a password and 2FA that protects your account (This is the authentication piece)
- The Persona Access Tokens are just for that, access

As for how you should be using them,

- I would refrain from using the same token across multiple machines. I would rather you create separate tokens for different machines (remember, you can attach a description to them so you know which one is for which device), so even if one were compromised, all you need to do is revoke that one (For example, let's say one of your devices has a catastrophic failure—just log into GitHub and revoke that one key).
- I encourage the use of credentials helpers, like Credentials Manager in Windows or Keychain Access on the Mac. Usually for me it's a one time task, and I don't tend to rotate my personal tokens that frequently so it's not that much of a big deal if I do decide to renew them.

Personally, I feel decoupling authentication from access makes sense—especially with 2FA. I know my password isn't shared across multiple devices—rather it's a (hard to break) token that is easily replaceable. Furthermore, connecting other services to GitHub using tokens puts my mind to rest—I know I don't have to share my GitHub password with third-party services.

I hope this helps. Please reach out if I can clarify anything further.

Regards,

[paul nisset]

Hi,
Thanks for your perspective.

I still believe storing passwords/access tokens on every machine is a stupid idea.
If one of my machines gets compromised, the gate has been opened and the horses are gone before I know about it.
Changing the locks/revoking the token after after someone has stolen my code is pretty useless at that point.
The fact that only one token or 5 has been compromised doesn't matter.

One scenario that having multiple tokens and keeping them on different machines makes sense is a team/group development environment where only one person/admin/owner can create tokens. That should have been an optional choice, not a forced one. For single code maintainer's, Github's change just created security holes and made access more of a pain than it needs to be.

In terms of storing them I use :
"git config credential.helper store" rather than the OS password manager mainly because I'm not sure how git interacts with external password managers.

I find credential.helper a useful feature and if it is built in to the product why not use that.


-Paul

[Raju Gandhi]

Hey Paul,

I can empathize with the plight of a single maintainer. I didn't know that had happened till a tech reviewer informed me that I had to rewrite two pages of my book b/c they changed the authentication mechanism.

But to your point

If one of my machines gets compromised, the gate has been opened and the horses are gone before I know about it.

If someone compromises a token they don't get to own your account, and therein lies the distinction I was trying to make. They can only push and pull, which, I agree, isn't something to trivialize, but they can't hijack your GitHub account. In a sense, one could think of this as a layered approach—each token gets a set of privileges attached, but to do anything of consequence, you need the password. You might have even noticed that in order to generate a new token, or even make a private repo public (or vice-versa) you need to supply GitHub with a password.

Now, if someone has compromised my machine, can they get to the password itself? Kinda depends on how I store those, but to your point, the horse may already have left the barn.

Regards,