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

Open Source

31717 readers
172 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
 

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
[–] mozz@mbin.grits.dev 0 points 11 months ago* (last edited 11 months ago)

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.