8 ms·

Github: Token authentication requirements for Git operations

112 points by politelemon 6y ago

greggman3 6y ago
Github auth's wording SUCKS! If all you ask for is "user" scope it will says this: > Example App by Company would like to permission to > * Verify your Github identity > * Know which resources you can access (WTF!) > * Act on your behalf (WTF!) Image: https://aws1.discourse-cdn.com/github/optimized/2X/b/b7744a53b85cd5cdaa81427d7091414e343ce3c5_2_670x750.png https://aws1.discourse-cdn.com/github/optimized/2X/b/b7744a5... If that was actually true it would be horrible. Apparently it's not true but github has been entirely unresponsive in fixing the wording. They claim 1. this is more appropriate wording 2. scopes with github vs oauth are exactly the same 3. oauth uses different wording Those 3 things can not all be true. If oauth scopes are the same they should have the same wording. They don't Here's a thread about it. Super frustrating https://github.community/t/why-does-this-forum-need-permission-to-act-on-my-behalf/120453 https://github.community/t/why-does-this-forum-need-permissi...
- mattarm 6y ago
  I find auth stuff to be a huge ball of frustration for everybody. It strikes me as if the people designing auth mechanisms and APIs and people designing usable UX are different species with different goals and value systems, and this leaks out all the way up to the user. In many ways this is just growing pains. For years people willingly handed their name/password to third party apps and sites, and this granted those sites full auth. This was too permissive, but extremely easy for people to understand, even for non-techies. With things like OAuth, OS level capabilities in iOS and Android, etc., we've now got to break down these "scopes" into slices that are flexible enough to write useful software against without being too broad, too revealing of the underling software architecture (brittle), and too confusing for the user. I think this is actually a really hard problem.
  - hpoe 6y ago
    Having worked as an Auth engineer for 5 years I can reaffirm not just does auth suck everyone doing auth in any capacity sucks. The analogy that I like to use that illustrates the problem is that Auth is like working with the DMV. No one wants to do it, everyone wants to get it over with as quickly as possible, it has a vast complicated structure that people don't want to know about or need to know about, it is usually painful, it doesn't actually give you any benefit but you have to do it anyway no matter who you are. Thus everyone is trying to hammer out the minimum they can to pass the minimum requirements and then try to forget it exists at all.
    - frenchy 6y ago
      Also, if you just ditch the whole enterprise, you end up with even worse problems.
  - wvh 6y ago
    I've been doing some auth development. Auth is hard because it's a deeply human problem, and therefore messy. Human beings share, cooperate cross-boundaries, self-organise and divide in all sorts of groups and hierarchies. There are policies and rules, and then there are unwritten rules and exceptions. On top of that, the planning phase of projects has lots of graphs and arrows of what needs to go where, but rarely includes the auth boundaries and permissions. It's an ungrateful job because basically you're throwing hurdles and setting limitations where everything would work by default in the utopia of an open internet (or intranet).
- JamesSwift 6y ago
  I read through that thread and it really is baffling. It seems more like a legal CYA wording than a technical/security wording. Really poorly handled on githubs side, either remove the wording or do a better job explaining the technical distinction.
  - Spivak 6y ago
    Like it’s super weird that they felt the need to be like “if you give someone your email address they might put together that you likely know the password to access your email.”
    - pests 6y ago
      They've been developing the system, have used it extensively, and have internalized all the details and quirks. They are just as confused at why that question is a question as OP was.
      - JamesSwift 6y ago
        Well thats part of my confusion. The initial response by them starts with > We understand that this is poorly and confusingly worded for this kind of scenario. We’ve given this feedback to the team that is responsible for how this dialog is designed. We’ll be working with them to improve it to hopefully make it more clear and understandable as to what exactly is being requested so that you can be more confident in the decision you’re being asked to make. Then they proceed to insist its fine as is. The fix seems simple. Just rework the layout so its in line with what was suggested in the thread (https://github.community/t/why-does-this-forum-need-permission-to-act-on-my-behalf/120453/15 https://github.community/t/why-does-this-forum-need-permissi...). No one even acknowledges this persons suggestion, even though it seems to be precisely what Github is trying to communicate.
- oefrha 6y ago
  Somewhat related auth scoping frustration: the v4 GraphQL API documentation doesn’t say what field/query/mutation need what scope, so you’re left guessing, or cross-referencing a related endpoint in API v3 documentation, or trial and error.
- glandium 6y ago
  Today I tried logging on Circle CI for the first time via github. The login stuff asked, among other things, for read/write access on all repositories, public or private. I didn't go through. I was later told that's not actually what happens in practice, but that permission prompt sure is scary.
xchip 6y ago
just so they know who to forward the lawsuits to
- lapinot 6y ago
  I hate github like every other guy, but this has nothing to do with the announcement. They're disallowing ssh password auth that's all, non-authenticated operations are fine and ssh pubkey auth is fine. Seems legit to me.
  - dathinab 6y ago
    > Seems legit to me. Fully so. I was super surprised when I happened to try to push on a temp. system which wasn't properly setup (no ssh key) and it asked me for my password. I'm also always surprised if e.g. password based SMTP for mail is still allowed (it most times is, but is a security problem, through not a big one). I just which the way to get the token (in general no github specific) would be better.
    - tialaramex 6y ago
      Authentication for email and other passive services is a bit trickier. For example suppose your mail server falls over, then is restarted. Does the mail client on your phone go "Hey, I need to re-authenticate to this server?" and meanwhile you don't receive any email? That's a not-great user experience. For SMTP this is a bit less fraught because at least the user presumably just did something to cause sending, so we can ask them to authenticate at that point. But that still can be a bit trickier than you'd like. There's also a much nastier backward compatibility story for email than for a relatively recent thing like GitHub. There absolutely will be a user with an Amiga 1200 using email on a big email service. Do you cut their service off? Maybe you have to, if that's the only way to secure service for other users. But it's a real last resort.
      - dathinab 6y ago
        > For example suppose your mail server falls over, If token based authentication is affected by this your mail server is doing things very very wrong. ---- I'm well aware about all the problems involved when it comes to mail/smtp auth by now. Still username+password auth done by any client for anything but the initial sign-up is a latent security vulnerability even if it's currently tricky to fix. -------- > There absolutely will be a user with an Amiga 1200 using email on a big email service. Do you cut their service off? Yes, if I would be a mail company I most likely would not have any reason to support them tbh. Probably a better example would be outdated outlook versions ;=)
varajelle 6y ago
Last time i tried to generate a token so an app could push to a repository of mine, but I wasn't able to limit the scope to only that repository, I had to give the app the right to push to all the repository I had access to, which I didn't want to. So I ended up creating a new account only for this app. So much for scoped access token.
- psanford 6y ago
  Could you not use a deploy key? They are scoped to at the repo level and you can optionally give them push access.
- OJFord 6y ago
  You can create one in the repo settings, just not from your user settings.
- deleted 6y ago
  [deleted]
3np 6y ago
The brownouts is something I’ve never seen done and announced like this before. It’s a great idea, triggering awareness and a sense of urgency without completely breaking things.
- rob-olmos 6y ago
  Relatedly, is "brownout" the best word for this case? If they did a percentage of auths or maybe intentionally made them take an excessively long time I could see it. Otherwise this looks more like planned blackouts. Or maybe an "auth flex period", since "brownout" or "blackout" might be offensive.
  - tialaramex 6y ago
    Brownout is the term I'm used to seeing for this practice. It's from electrical distribution where a brownout is distinct from blackout because you are delivering electricity but not as specified (e.g. voltage sag beyond agreed limits) and on simple incandescent lights the effect is they're dimmer than before. I don't think it has any greater claim to being offensive than blackout (from electrical distribution) or whiteout (from weather reporting)
    - rob-olmos 6y ago
      I believe that's what I'm saying, password auth isn't being dimmed, it's experiencing a blackout. Ie, "password authentication blackout". Regarding the offensiveness, I was hinting at GitHub's prior remarks for racial sensitivity: https://news.ycombinator.com/item?id=23500093 https://news.ycombinator.com/item?id=23500093 -- among the many other projects that have actively changed black/white to block/allow and other variations.
      - jackson1442 6y ago
        I honestly think block/allow is better language-- black/whitelist is something I had to look up when I first encountered it, so you might as well use language that isn't idiomatic and follows literal textbook definitions.
OJFord 6y ago
Confusingly written here ('must now use a token ... unaffected if you already use 2FA, as you're then required to use a token or SSH key' - so.. if I use 2FA and SSH key?) but per the linked original announcement, you can indeed carry on like nothing happened if you already use SSH, i.e. your remotes are git@github.com:blah/blah
HelloNurse 6y ago
It looks like a significant step towards convergence with the token authentication already in use on Azure-hosted repositories, but of course it's for security reasons. In the cloud the traditional embrace, extend and extinguish business plan becomes embrace, extend and extort.
mnd999 6y ago
So ssh key is still fine. Nothing to see here. Move along.
- nine_k 6y ago
  The most interesting bit here for me is that some users are not using SSH keys for git operations. I wonder how many.
  - strogonoff 6y ago
    Which Git implementations, apart from reference CLI, support SSH key authentication? Isomorphic Git (which we use) doesn’t, for example. Not sure I particularly want it to, either—such a feature would probably bring in a host of dependencies but not much to the table compared to a scoped PAT.
    - terinjokes 6y ago
      Most should, or at least have it on the roadmap. There are many Git repositories, off GitHub, that are only accessible with SSH authentication.
      - strogonoff 6y ago
        Really? Why? Seems like it would unnecessarily restrict the range of compatible clients.
    - nine_k 6y ago
      I suppose GIT implementations are mostly transport-agnostic, and specific apps connect them to remote transports. E.g. JGit is widely used and has no notion of SSH keys, but GitBlit can serve a GIT repo over SSH using JGit, and JetBrains IDEs can access GIT repos served over SSH using some kind of pure Java SSH implementation (not sure which); I remember they used to use JGit, too.
    - tialaramex 6y ago
      At least Jgit (the Java implementation) does this correctly. It seems very weird to do SSH at all without using SSH keys. The core SecSH (ie SSH 2) protocol design assumes you have SSH keys, offering password authentication only as an optional extra feature. Now of course the IETF does not have an enforcement arm, and I have seen implementations that don't work like that, but to me this is an obvious red flag, like a stub plugged in to stop the seat belt alarm going off, "I know that what I'm doing is very stupid, so I worked harder to do it anyway". OK then.
andrepew 6y ago
It would be awesome if they added support for FIDO hardware keys since it is supported by OpenSSH 8.2. PIV/GPG based solutions are a pain in the butt to use.
recursive 6y ago
I don't understand this. It says I need to begin using a "personal access token" and links here. https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/set-up-git#next-steps-authenticating-with-github-from-git https://docs.github.com/en/free-pro-team@latest/github/getti... The target document says nothing about any kind of tokens. I'm just a regular guy with some github repos. Am I going to get locked out?
- tialaramex 6y ago
  You won't get locked out. If you use the GitHub APIs (you probably don't as a "regular guy with some github repos") you need to adjust how you do that to use tokens. If you haven't adjusted before they get rid of the legacy authentication you'll have to manually log into your GitHub account and read up how to do it then or your API calls break. If you use HTTPS URLs to refer to your github repos (more likely on Windows) from Git then you need to get tokens by the deadline to make that work. Or, switch to using SSH URLs for your repositories if that seems easier. If, like a great many GitHub users, neither applies, you don't need to do anything, it will continue to work as before. As a rule of thumb, think about your GitHub password. Anywhere you have to keep typing that in (other than the actual GitHub sign in page) or you've saved it to be re-used over and over, that will stop working. That was always a bad idea, and now it will stop working.
asiachick 6y ago
IIUC github tokens are just a giant fiasco waiting to happen. Tokens are a password that "just works" and people are giving them out like candy to every company and service that integrates with github. If stolen (just like a password breach) the thieves can use those tokens to check in whatever random code they want into all your repos. This means they not only effect you (like when your bank password is stolen), they also affect everyone down stream of you. Tons of sites ask for effectively "Full permissions" and people give them full permission. They then get a token. If that token leaks the thief gets those full permissions

112 points by politelemon 6y ago

Github auth's wording SUCKS! If all you ask for is "user" scope it will says this: > Example App by Company would like to permission to > * Verify your Github identity > * Know which resources you can access (WTF!) > * Act on your behalf (WTF!) Image: https://aws1.discourse-cdn.com/github/optimized/2X/b/b7744a53b85cd5cdaa81427d7091414e343ce3c5_2_670x750.png https://aws1.discourse-cdn.com/github/optimized/2X/b/b7744a5... If that was actually true it would be horrible. Apparently it's not true but github has been entirely unresponsive in fixing the wording. They claim 1. this is more appropriate wording 2. scopes with github vs oauth are exactly the same 3. oauth uses different wording Those 3 things can not all be true. If oauth scopes are the same they should have the same wording. They don't Here's a thread about it. Super frustrating https://github.community/t/why-does-this-forum-need-permission-to-act-on-my-behalf/120453 https://github.community/t/why-does-this-forum-need-permissi...

mattarm 6y ago
I find auth stuff to be a huge ball of frustration for everybody. It strikes me as if the people designing auth mechanisms and APIs and people designing usable UX are different species with different goals and value systems, and this leaks out all the way up to the user. In many ways this is just growing pains. For years people willingly handed their name/password to third party apps and sites, and this granted those sites full auth. This was too permissive, but extremely easy for people to understand, even for non-techies. With things like OAuth, OS level capabilities in iOS and Android, etc., we've now got to break down these "scopes" into slices that are flexible enough to write useful software against without being too broad, too revealing of the underling software architecture (brittle), and too confusing for the user. I think this is actually a really hard problem.
- hpoe 6y ago
  Having worked as an Auth engineer for 5 years I can reaffirm not just does auth suck everyone doing auth in any capacity sucks. The analogy that I like to use that illustrates the problem is that Auth is like working with the DMV. No one wants to do it, everyone wants to get it over with as quickly as possible, it has a vast complicated structure that people don't want to know about or need to know about, it is usually painful, it doesn't actually give you any benefit but you have to do it anyway no matter who you are. Thus everyone is trying to hammer out the minimum they can to pass the minimum requirements and then try to forget it exists at all.
  - frenchy 6y ago
    Also, if you just ditch the whole enterprise, you end up with even worse problems.
- wvh 6y ago
  I've been doing some auth development. Auth is hard because it's a deeply human problem, and therefore messy. Human beings share, cooperate cross-boundaries, self-organise and divide in all sorts of groups and hierarchies. There are policies and rules, and then there are unwritten rules and exceptions. On top of that, the planning phase of projects has lots of graphs and arrows of what needs to go where, but rarely includes the auth boundaries and permissions. It's an ungrateful job because basically you're throwing hurdles and setting limitations where everything would work by default in the utopia of an open internet (or intranet).
JamesSwift 6y ago
I read through that thread and it really is baffling. It seems more like a legal CYA wording than a technical/security wording. Really poorly handled on githubs side, either remove the wording or do a better job explaining the technical distinction.
- Spivak 6y ago
  Like it’s super weird that they felt the need to be like “if you give someone your email address they might put together that you likely know the password to access your email.”
  - pests 6y ago
    They've been developing the system, have used it extensively, and have internalized all the details and quirks. They are just as confused at why that question is a question as OP was.
    - JamesSwift 6y ago
      Well thats part of my confusion. The initial response by them starts with > We understand that this is poorly and confusingly worded for this kind of scenario. We’ve given this feedback to the team that is responsible for how this dialog is designed. We’ll be working with them to improve it to hopefully make it more clear and understandable as to what exactly is being requested so that you can be more confident in the decision you’re being asked to make. Then they proceed to insist its fine as is. The fix seems simple. Just rework the layout so its in line with what was suggested in the thread (https://github.community/t/why-does-this-forum-need-permission-to-act-on-my-behalf/120453/15 https://github.community/t/why-does-this-forum-need-permissi...). No one even acknowledges this persons suggestion, even though it seems to be precisely what Github is trying to communicate.
oefrha 6y ago
Somewhat related auth scoping frustration: the v4 GraphQL API documentation doesn’t say what field/query/mutation need what scope, so you’re left guessing, or cross-referencing a related endpoint in API v3 documentation, or trial and error.
glandium 6y ago
Today I tried logging on Circle CI for the first time via github. The login stuff asked, among other things, for read/write access on all repositories, public or private. I didn't go through. I was later told that's not actually what happens in practice, but that permission prompt sure is scary.

xchip 6y ago

just so they know who to forward the lawsuits to

lapinot 6y ago
I hate github like every other guy, but this has nothing to do with the announcement. They're disallowing ssh password auth that's all, non-authenticated operations are fine and ssh pubkey auth is fine. Seems legit to me.
- dathinab 6y ago
  > Seems legit to me. Fully so. I was super surprised when I happened to try to push on a temp. system which wasn't properly setup (no ssh key) and it asked me for my password. I'm also always surprised if e.g. password based SMTP for mail is still allowed (it most times is, but is a security problem, through not a big one). I just which the way to get the token (in general no github specific) would be better.
  - tialaramex 6y ago
    Authentication for email and other passive services is a bit trickier. For example suppose your mail server falls over, then is restarted. Does the mail client on your phone go "Hey, I need to re-authenticate to this server?" and meanwhile you don't receive any email? That's a not-great user experience. For SMTP this is a bit less fraught because at least the user presumably just did something to cause sending, so we can ask them to authenticate at that point. But that still can be a bit trickier than you'd like. There's also a much nastier backward compatibility story for email than for a relatively recent thing like GitHub. There absolutely will be a user with an Amiga 1200 using email on a big email service. Do you cut their service off? Maybe you have to, if that's the only way to secure service for other users. But it's a real last resort.
    - dathinab 6y ago
      > For example suppose your mail server falls over, If token based authentication is affected by this your mail server is doing things very very wrong. ---- I'm well aware about all the problems involved when it comes to mail/smtp auth by now. Still username+password auth done by any client for anything but the initial sign-up is a latent security vulnerability even if it's currently tricky to fix. -------- > There absolutely will be a user with an Amiga 1200 using email on a big email service. Do you cut their service off? Yes, if I would be a mail company I most likely would not have any reason to support them tbh. Probably a better example would be outdated outlook versions ;=)

varajelle 6y ago

Last time i tried to generate a token so an app could push to a repository of mine, but I wasn't able to limit the scope to only that repository, I had to give the app the right to push to all the repository I had access to, which I didn't want to. So I ended up creating a new account only for this app. So much for scoped access token.

psanford 6y ago
Could you not use a deploy key? They are scoped to at the repo level and you can optionally give them push access.
OJFord 6y ago
You can create one in the repo settings, just not from your user settings.
deleted 6y ago
[deleted]

3np 6y ago

The brownouts is something I’ve never seen done and announced like this before. It’s a great idea, triggering awareness and a sense of urgency without completely breaking things.

rob-olmos 6y ago
Relatedly, is "brownout" the best word for this case? If they did a percentage of auths or maybe intentionally made them take an excessively long time I could see it. Otherwise this looks more like planned blackouts. Or maybe an "auth flex period", since "brownout" or "blackout" might be offensive.
- tialaramex 6y ago
  Brownout is the term I'm used to seeing for this practice. It's from electrical distribution where a brownout is distinct from blackout because you are delivering electricity but not as specified (e.g. voltage sag beyond agreed limits) and on simple incandescent lights the effect is they're dimmer than before. I don't think it has any greater claim to being offensive than blackout (from electrical distribution) or whiteout (from weather reporting)
  - rob-olmos 6y ago
    I believe that's what I'm saying, password auth isn't being dimmed, it's experiencing a blackout. Ie, "password authentication blackout". Regarding the offensiveness, I was hinting at GitHub's prior remarks for racial sensitivity: https://news.ycombinator.com/item?id=23500093 https://news.ycombinator.com/item?id=23500093 -- among the many other projects that have actively changed black/white to block/allow and other variations.
    - jackson1442 6y ago
      I honestly think block/allow is better language-- black/whitelist is something I had to look up when I first encountered it, so you might as well use language that isn't idiomatic and follows literal textbook definitions.

OJFord 6y ago

Confusingly written here ('must now use a token ... unaffected if you already use 2FA, as you're then required to use a token or SSH key' - so.. if I use 2FA and SSH key?) but per the linked original announcement, you can indeed carry on like nothing happened if you already use SSH, i.e. your remotes are git@github.com:blah/blah

HelloNurse 6y ago

It looks like a significant step towards convergence with the token authentication already in use on Azure-hosted repositories, but of course it's for security reasons. In the cloud the traditional embrace, extend and extinguish business plan becomes embrace, extend and extort.

mnd999 6y ago

So ssh key is still fine. Nothing to see here. Move along.

nine_k 6y ago
The most interesting bit here for me is that some users are not using SSH keys for git operations. I wonder how many.
- strogonoff 6y ago
  Which Git implementations, apart from reference CLI, support SSH key authentication? Isomorphic Git (which we use) doesn’t, for example. Not sure I particularly want it to, either—such a feature would probably bring in a host of dependencies but not much to the table compared to a scoped PAT.
  - terinjokes 6y ago
    Most should, or at least have it on the roadmap. There are many Git repositories, off GitHub, that are only accessible with SSH authentication.
    - strogonoff 6y ago
      Really? Why? Seems like it would unnecessarily restrict the range of compatible clients.
  - nine_k 6y ago
    I suppose GIT implementations are mostly transport-agnostic, and specific apps connect them to remote transports. E.g. JGit is widely used and has no notion of SSH keys, but GitBlit can serve a GIT repo over SSH using JGit, and JetBrains IDEs can access GIT repos served over SSH using some kind of pure Java SSH implementation (not sure which); I remember they used to use JGit, too.
  - tialaramex 6y ago
    At least Jgit (the Java implementation) does this correctly. It seems very weird to do SSH at all without using SSH keys. The core SecSH (ie SSH 2) protocol design assumes you have SSH keys, offering password authentication only as an optional extra feature. Now of course the IETF does not have an enforcement arm, and I have seen implementations that don't work like that, but to me this is an obvious red flag, like a stub plugged in to stop the seat belt alarm going off, "I know that what I'm doing is very stupid, so I worked harder to do it anyway". OK then.

andrepew 6y ago

It would be awesome if they added support for FIDO hardware keys since it is supported by OpenSSH 8.2. PIV/GPG based solutions are a pain in the butt to use.

recursive 6y ago

I don't understand this. It says I need to begin using a "personal access token" and links here. https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/set-up-git#next-steps-authenticating-with-github-from-git https://docs.github.com/en/free-pro-team@latest/github/getti... The target document says nothing about any kind of tokens. I'm just a regular guy with some github repos. Am I going to get locked out?

tialaramex 6y ago
You won't get locked out. If you use the GitHub APIs (you probably don't as a "regular guy with some github repos") you need to adjust how you do that to use tokens. If you haven't adjusted before they get rid of the legacy authentication you'll have to manually log into your GitHub account and read up how to do it then or your API calls break. If you use HTTPS URLs to refer to your github repos (more likely on Windows) from Git then you need to get tokens by the deadline to make that work. Or, switch to using SSH URLs for your repositories if that seems easier. If, like a great many GitHub users, neither applies, you don't need to do anything, it will continue to work as before. As a rule of thumb, think about your GitHub password. Anywhere you have to keep typing that in (other than the actual GitHub sign in page) or you've saved it to be re-used over and over, that will stop working. That was always a bad idea, and now it will stop working.

asiachick 6y ago

IIUC github tokens are just a giant fiasco waiting to happen. Tokens are a password that "just works" and people are giving them out like candy to every company and service that integrates with github. If stolen (just like a password breach) the thieves can use those tokens to check in whatever random code they want into all your repos. This means they not only effect you (like when your bank password is stolen), they also affect everyone down stream of you. Tons of sites ask for effectively "Full permissions" and people give them full permission. They then get a token. If that token leaks the thief gets those full permissions