this post was submitted on 24 Jan 2024
255 points (90.7% liked)

Open Source

31031 readers
465 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
Cloak@lemmy.ml
kevincox@lemmy.ml
CrypticCoffee@lemmy.ml
Lettuceeatlettuce@lemmy.ml
255
Enshittification of GitHub? (lemmy.ml)
submitted 9 months ago by antrosapien@lemmy.ml to c/opensource@lemmy.ml
115 comments fedilink hide all child comments
 

First, they restricted code search without logging in so I'm using sourcegraph But now, I cant even view discussions or wiki without logging in.

It was a nice run

you are viewing a single comment's thread
view the rest of the comments
[–] ReversalHatchery@beehaw.org 1 points 9 months ago (1 children)

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

By copy-pasting it somewhere it has access to it. It can be the config file, it has several ways to use the system's secret storage, and you can also autotype it from your password manager every time if you want.

forced to save my token to persistent storage in a way I wouldn't be with a password

So not really

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?

Passwords can be short and simple. API tokens are lengthy and random, and you can't change that. Also, you never type in your API key, and that can help against shoulder- and camera-surfing.

without doing anything to disable the existing point of access

You can't do that, because

  • the API token is strictly for API access for outside programs
  • the API token cannot be used to manage your account, like change password or emails, or to create additional tokens

API tokens are not a total replacement, just a more secure and restricted replacement for the everyday and not too risky tasks and for automated systems.

[–] mozz@mbin.grits.dev 1 points 9 months ago* (last edited 9 months ago) (1 children)

I think this comment pretty well summarizes my argument on it. The only parts not addressed:

Passwords can be short and simple. API tokens are lengthy and random, and you can't change that.

You can, as most modern web services including github do, have a minimum length and complexity for the password. That's a very important part of the process yes.

Plus, you seem to still not be grasping the core of my argument: github still authenticates with a password. You can still log in to the web site and change everything, if you compromise someone's password, whether because it's insufficiently complex or for any other reason.

Also, you never type in your API key, and that can help against shoulder- and camera-surfing.

I would like to see a quantitative comparison of how many github compromises there have been because of a stolen API token vs. compromises of some comparable service from a shoulder-surfed password.

[–] ReversalHatchery@beehaw.org 1 points 9 months ago (2 children)

You can, as most modern web services including github do, have a minimum length and complexity for the password. That's a very important part of the process yes.

Sorry, I wasn't clear. What I wanted to say is that passwords can be insecure, and in the case of lazy people that had consequences on security. I think the minimum is often not really secure, it's just "fine if you really must" but allowed to not lose to many users.
And at the same time tokens are always secure. It's not defined by the user, they cannot lazy it away, it's made equally complicated for everyone. Fortunately they don't have to type it either, it's copy paste and done.

However I have to admit that while writing this response, complexity is not really the point with github access tokens.

Plus, you seem to still not be grasping the core of my argument: github still authenticates with a password. You can still log in to the web site and change everything, if you compromise someone's password, whether because it's insufficiently complex or for any other reason.

That's right, these tokens won't protect the lazy from their account being taken over. But I think these are still more secure for their use case: storing them in mostly text files, because the programs to which you give these will probably do that, and as these are not really password-equivalent things (these have very limited access to your account), it's less of a problem.

Your original question here was how will it be more secure that we are storing these tokens in our password managers besides our passwords. My answer is that even if you put it into your password manager, that's not it's final place: it will probably end up in text files and other such places, and if such a file gets into the wrong hands you'll be in less of a trouble because of the limited permissions. If you would have stored your password there, you could be hoping that you'll get your account back, and that the person did not do anything bad in your name.

I think much of the confusion is coming from you believing that api tokens are equivalent to passwords. That's not the case. Even if you give all possible permissions to a token, it won't be able to do everything that you can do with the password through the website. In short, the main point here is that you don't have to use your password in places where that's totally unnecessary, and fewer permissions are fine.

[–] mozz@mbin.grits.dev 1 points 9 months ago (1 children)

it will probably end up in text files and other such places, and if such a file gets into the wrong hands you'll be in less of a trouble because of the limited permissions

I am abandoning this conversation. This is only true with API tokens. With passwords, it generally stays in the password manager. The fact that the damage from your stolen API token is then mitigated if you've reduced its scope still leaves you in a worse position than if it had never been stored in the text file and never been stolen in the first place. If you can't or won't grasp this central point (or the other I mentioned in my other message), I think we have nothing to discuss.

[–] ReversalHatchery@beehaw.org 1 points 9 months ago (2 children)

The fact that the damage from your stolen API token is then mitigated if you've reduced its scope still leaves you in a worse position than if it had never been stored in the text file and never been stolen in the first place.

First, it's not a question if you have reduced it's permissions. With an api token you simply can't do a lot of things that you can with a password.

Second, you don't use api tokens as a hobby. You use them because you want to use a tool that needs to have access to your account. Either you use an api token that has a limited set of permissions, or your password that can do anything. Independently of that, it will be stored in a plain text file, because where in the heaven would it store it so that it does not need to prompt you for it every single time? Yes, there are a dozen secret store programs that could be used instead, but a lot of programs will not have support for every one of them. I fail to see that in case how a token with fewer permissions is worse than a password with all the permissions.

[–] mozz@mbin.grits.dev 1 points 9 months ago* (last edited 9 months ago)

Case in point. This literally just happened to me just now:

me@My-MacBook content % brew install projectdiscovery/tap/httpx
==> Tapping projectdiscovery/tap
Cloning into '/usr/local/Homebrew/Library/Taps/projectdiscovery/homebrew-tap'...
Username for 'https://github.com': me
Password for 'https://me@github.com': 
remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Authentication failed for 'https://github.com/projectdiscovery/homebrew-tap/'
Error: Failure while executing; `git clone https://github.com/projectdiscovery/homebrew-tap /usr/local/Homebrew/Library/Taps/projectdiscovery/homebrew-tap --origin=origin --template= --config core.fsmonitor=false` exited with 128.

Boy, I sure am glad I'm more secure now. I think the easiest way to get out of this is literally to make a new API token just for me to be able to type to this command. Time to log in to github and spend a few minutes not accomplishing what I was trying to do originally.

As I said before, using API tokens for genuine automated access, I'm all for. An easy way might be to only support typing passwords on interactive ttys or something, and enforce API tokens otherwise. But as it is, and especially given the fact that they're specifically reducing the security of the interactive case, it's hard not to be irritated when this kind of thing happens.

Edit: Oh, and it made me type my password into the github web site in order to generate the token. Hope no one's shoulder- or camera-surfing me.

Also, I was following old instructions anyway; the command failed and I learned I should have just done brew install httpx. I wish github was configured so I could have learned that 10 minutes ago.

[–] mozz@mbin.grits.dev 1 points 9 months ago* (last edited 9 months ago)

Aha, I think we have arrived at the crux of the confusion.

As I said several times before, I'm extremely in favor of using API tokens that way, when they're being used from an automated workflow where the alternative is to store a password. That's an increase in security, yes.

What I'm irritated about is that my use of git as a command-line tool does not function to interact with github if I just give my github password. I do not have an automated workflow. I'm just using git from the command line, and would like to be able to type my password.

If this reduction in the security and convenience of my daily setup is because github believes, as you do apparently, that the only reason to use the command line is from an automated workflow, that may form a clue as to why they don't give a shit about my preferred workflow or my not wanting to introduce new attack vectors into it. Fair enough. But please don't lecture me on how not letting me just enter my password, and forcing me to store tokens for my interactive workflow, is better. Because for me, it isn't.

Glad we had this talk.

[–] mozz@mbin.grits.dev 1 points 9 months ago* (last edited 9 months ago)

Can you really not understand that the github web site still uses passwords? And that these users you describe still need to know and use their github password in order to use github? So all the issues you describe with passwords still exist under github's current security model. You're getting that I'm saying that, right? I have more to say but I wanna pause for a second to focus on that point. If github really had replaced passwords with some other approach, or added a layer to their password security (e.g. enforced semi-2FA like Google does) I'd have a whole different take on it.

And, please don't say things like "much of the confusion." It's condescending and wrong to imply that the only possible reason we could be disagreeing is that I'm confused.