Oh, API tokens in general, I think are great. As an additional layer of security between “I need my program to be able to access this API” and “I type my password”, they are great. My issue is with the specific way that github has implemented them.

An API token is more secure than a password by virtue of it not needing to be typed in by a human.

Remind me. When I create my API token, how do I provide it to git?

Am I, more or less, forced to save my token to persistent storage in a way I wouldn’t be with a password? I realize that most people store either one in a password manager at this point. My point is, if you’re going to store your password-equivalent in a password manager, how have you achieved greater security as compared with storing a password in the same password manager? How is that not just adding another compromise vector?

Phishing

Remind me. Does making a system significantly more complex mean that phishing gets easier? Or harder?

As an example, if someone can phish my password from me to compromise my security, is that better or worse than if they can either phish my password or else compromise my tokens? I remember this compromise for example, but I can’t remember whether it involved passwords or tokens.

writing down passwords

Remind me. Help me understand. Can someone write down their github password if the API token system exists? If they have to use it sometimes to log in to the web site anyway?

and the fact that API tokens can have restricted scopes

Yes. API tokens are a good system, in general, and restricting the scope of what they can do and making them time-limited are good reasons why.

My argument is that, in general, (a) adding an additional point of access to a system without doing anything to disable the existing point of access, and (b) saving a password equivalent to someone’s system instead of having the “standard way” be for them to retype their password to authenticate each session but not have it saved anywhere, are both overall reductions in security.

I get the motivation that github sometimes protects really critical stuff, and so it needs to be more secure. I am saying that their particular implementation of API tokens led to an overall reduction in security as opposed to an increase.

Let’s go over the attack vectors involved for different common workflows. I’m going to use the specific case of how I use git.

1. Store passwords in pass, have them memorized and type them anew every time
2. Store passwords in pass, store API tokens in OSX keychain

Which is more secure? The thing that you’re saying is better-protected because it’s limited, doesn’t exist in workflow #1. The tokens aren’t limited to push and pull, because they’re limited to nothing.

If someone gets my password in case #2, they can still do anything. That’s my central point – you haven’t removed any point of vulnerability, you’ve created another point of vulnerability and then mandated that people use it. And this isn’t an abstract issue; there are several compromises of github data stemming from people’s API tokens being compromised. My assertion is that in some of those cases, using case #1 instead of storing the API tokens would have prevented the compromise. Maybe I am wrong in that. I know that password compromises happen too. But my point is, you’re not preventing anybody from getting their password compromised. Someone can still steal my password out of pass. Someone who puts a keylogger on my computer will have the passwords to my OSX keychain and pass, both. You’re simply introducing another point of compromise, additional to password compromises, and mandated storage of your new password-equivalents on storage where before you at least had the option of memorizing them and typing them every time.

Edit: And just to say it again, I have no problem with API tokens. If someone’s got an automated workflow set up, such that they have to set up a password-equivalent on their script that accesses github, they should absolutely create a usage-restricted API token and use that instead. I’m talking more specifically about the decision to ban people from typing their passwords when they want to interact with github, pretending that somehow that makes compromising the un-usage-restricted password impossible (when it doesn’t at all), and forcing people to store auth tokens in their local storage when they’d rather type their password every time.

it’s obviously the same in github OP don’t know what is talking about lol