How is using a token as a command-line password any safer than using my own pass-phrase?

In fact, in my opinion it is less secure. I just created a throw-away Linux environment to do some off-site development. I used GitHub to clone some repos from the command line, and got the “Deprecation Notice” e-mail that many have seen.

So I read the advice, which amounts to:

“Don’t use your long, easily-remembered, but difficult-to-type pass-phrase that you’ve never told anyone as your password: instead use this password that we gave you, that will never change, and you have no hope of remembering so have to carry around with you everywhere in plaintext.”

How is my pass-phrase any worse than the fixed, never-changing (unless I change my actual password - ahem?) ASCII token?

“Use a password manager” seems to be a suggestion. This is a throwaway environment. You’re asking me to install additional software, and copy files from another machine? Maybe I should store my password manager database in a public GitHub repository then, so I can get it on whatever other machine I’m setting up. (Does the same database file work on both Linux and Windows?)

Sorry, but this is a step backwards in both security and convenience. Normally convenience is forced to give way to better security - but this reduces both simultaneously.

2 Likes

You can regenerate a token at any time to change it.

For the password manager, there’s no need to install it on each and every machine. You can just enter the token over the command line like you would your password (including copy&paste). And yes, at least with KeepassXC or Keepass2 the same DB works on Linux and Windows.

As for security differences:

  • A stolen password lets the attacker do much more damage than a token. The narrower the scopes the less damage a stolen token can do.
  • Without a password manager most people reuse passwords for multiple sites, or use too simple passwords (often both). Which is understandable because very few people can remember a dozen or more strong passwords (if you can, that’s awesome!), but creates huge security problems.
1 Like

@airtower-luna Thanks for your response, but I disagree with you on a few points:

  1. I don’t really care that I can change the token - I can equally change my pass-phrase when I want. The effect is the same, so there’s no difference.
  2. For me to enter the password on a new machine, I need to know what it is. Before, I had a ~32-character pass-phrase that I could remember. Now, I’m being given a password that I’m required to use that I can’t remember, so I have to store it somehow, somewhere, in cleartext. Or put it in an encrypted database, and post it in a public place so that I can access it when I need it and hope that it won’t get cracked by anyone else.
  1. a) A password can only be stolen if it is explicitly provided by the owner, written down, or intercepted in-use. I don’t write my remembered pass-phrase down, but I have to write my given password down, so that means the given password is less secure. Either password usage can be intercepted in-use, so there’s no improvement in security there.
  1. b) How does a stolen pass-phrase differ from a stolen token? You enter either of them at the same point in whatever operation you’re performing. I can do whatever I used to do with the old pass-phrase with the new token - they have exactly the same scope as far as I can see.
  2. I agree with your analysis about “most people”. However I don’t do any of what you describe - and not because I have an awesome memory. I use a password system, that I have never told anyone. Given where I need to enter a password, I can use my system to generate the appropriate pass-phrase - with perhaps one or two misses - and it guarantees that no two are the same. Every time I used my system on a password-checking website, it has always resulted in the top-most classification of password strength. In fact, it sometimes challenges websites that have a small upper limit to the number of characters (hence the occasional failure).

Frankly, what you’re arguing is:

“It’s more secure for you to use this password than your invented password - because you might have invented a weak one.”

And that is simply incorrect. Imposing a long random non-word requires everyone to do something that is either insecure or inconvenient, when I had a perfectly acceptable, less inconvenient, more secure alternative. So they need to improve their password validation (although that won’t help password re-use) rather than dictating the password to use - which is effectively what they’ve done.

Ultimately, if a password is cracked and IP is stolen, whose fault is that? The inventor of the password - and that is GitHub if they dictate the password to use.

Just to be clear: I don’t work for GitHub, I don’t make decisions over login mechanisms or anything else for them. I’m just trying to clear up some misconceptions. If you think tokens are horribly inconvenient, I’m the wrong person to yell at. :slightly_smiling_face:

Again, there’s absolutely no need to post a password manager DB anywhere. You can keep in on a personal device and use it only from there.

You can select the scopes for the token when you create it (and even change them later). The token will only be usable for the scopes you select. I consider this a huge advantage.

On the other hand, a stolen password can lead to full account compromise, if the attacker can find a way around 2FA or mail verification. API access with the password has been deactivated for a few months now (in favor of tokens only), before that the attacker would’ve also been able to do all sort of fun things to your account over the API.

2 Likes

@airtower-luna Sorry! I didn’t mean to suggest you were in the inner circle - and I hope I wasn’t “yelling”, merely frustrated. I’m talking into the Cloud here, and you’re giving me the opportunity to vent: not at yourself, merely at what the perceptions are at GitHub when they instituted these changes.

Yes, I agree that a token has finer resolution than a be-all-and-end-all password; however think of my scenario. I don’t know what the token will be used for in the future, so I have two choices:

  1. Create a single token that can do anything, to guard against what I might need to do in the future - or alternatively add an “Administrative” option to that token which means effectively the same thing;

  2. Create a number of different tokens, and be careful of which I use for which purpose.

The second option basically exacerbates my problem: yet more passwords that I have to manage and “remember” - whether that’s through a DB manager or a PDA-equivalent. And the most fundamental thing I would want to do is to read the information in the repo: if there’s a security breach of whatever, there goes my IP.

Which goes back to the initial problem. You say I don’t need to post my password DB; instead I should put it on my “personal” device (my ‘PDA’ described above). I. Don’t. Have. A. PDA. OK, I do - it’s my brain. Sure, I can institute a whole new procedure specifically for GitHub. And it may very well be that this is the “thin edge of the wedge” and everyone will enforce the equivalent of tokens or certificates from now on, and GitHub is merely the first. That makes me the grumpy codger yelling “Get Off My Lawn” as change is happening around me - but at the same time I’m highlighting the myopic nonsense of what GitHub has done. They’ve replaced my password with their password: THAT’S IT.

Yeah, that was the exact same conclusion I came to as well.

As I see it its no more secure than what I had before.
And for someone that only uses git for small personal projects,
this is just an unwanted inconvenience.

I wish they’d split these changes out, so it only affected enterprise users, and those
using git for business purposes.

This has put my project on hold because I can’t figure out how to use the new token
to commit from the command line, when it used to be so simple.

Now I need support just to do something I was previously able to without issue.

apparently several people have the same issue, so its possibly a bug/oversight on gits end?
I’ve seen several threads on the same topic pop up recently.

No general solutions yet though.

It’s definitely not more secure because now I have to put what’s essentially a password onto shared machines and github has no way of requiring a password to use the token like you can with ssh so PAT is a fucking joke and I’m not sure how GitHub’s staff could possibly think this is a good idea with the countless times that NPM has been exploited because of this same problem.

Tokens make sense for API’s, passwords make sense for humans. Not everyone uses VSCode and GitHub Desktop like Microsoft wants us to

If you put your token into a shared machine, you previously put your password there, which is way worse. A token has limited rights, the password gives full access to your account.

You should not be storing either on a shared machine. Use a password manager with decent encryption. And you should have the password manager on your own machine, so a potential attacker on the shared one can’t steal its password when you unlock it.