Github: Token authentication requirements for Git operations
github.blog
github.blog
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/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-permissi...
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.
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.
> 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-permissi...). No one even acknowledges this persons suggestion, even though it seems to be precisely what Github is trying to communicate.
I was later told that's not actually what happens in practice, but that permission prompt sure is scary.
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)
Regarding the offensiveness, I was hinting at GitHub's prior remarks for racial sensitivity: https://news.ycombinator.com/item?id=23500093 -- among the many other projects that have actively changed black/white to block/allow and other variations.
The idea is that even though you wrote a blog post, maybe sent out formal notices to users, even in some cases put up billboards or did PSAs on TV - some people won't know it applies to them, or may even mistakenly believe it doesn't apply even though it does.
The brownout is an opportunity for those people to notice. "Hey, why doesn't the Foozle work?" "I dunno. Ask on Reddit?" "Huh. Reddit says we need to use tokens, but I'm sure we... oh... did you actually update the Foozle script?" "I thought you were doing that" "D'oh".
Users who can't react immediately when things go bang will get a reprieve - for a while - when it starts working again the next day.
So that's why "blockout" isn't an appropriate description.
There's some degree of art and some science to planning these so that they're disruptive enough that humans notice something went wrong, while not being disruptive enough that they're worse than just a one shot change.
I don't want to beat a dead horse at this point, but that's basically a planned blackout. It'd be similar to a power company cutting off a residence's power for a couple hours to remind them to pay their overdue bill. I can't see that being correctly called a brownout.
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.
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.
I see about two possible cases:
1) One uses Git CLI and wants to get rid of incessant password prompts this way.
2) One has a setup in which multiple servers access a private Git repo, and wants each server to use different credentials.
This doesn’t seem worth the trouble in simpler scenarios when the user accesses Git from one or two personal machines and is entirely fine just changing their password/revoking PAT if it is compromised.
In HTTPS the model is, you and the server both know a secret, your "password" and then you... just tell them your secret each time to authenticate.
That's a pretty good model if you're a ten year old playing forts out in the woods, but it's far below what we ought to be achieving for a service like this.
It's true that this plaintext password authentication is normal for the web, which is basically Tim (Berners-Lee)'s fault but that doesn't magically make it a good idea, and it makes sense that GitHub doesn't want "Yes it's crap but it's no worse than the web" to be all they're delivering.
The relying party (GitHub in this case) learn nothing secret. Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them.
A MITM learns nothing secret. If things go wrong and you somehow allow a MITM attack to occur, the MITM doesn't get durable credentials from you, once you are talking to GitHub not the MITM they're locked out, even though they watched you authenticate successfully, perhaps many times, they do not learn how to forge working credentials.
> If things go wrong and you somehow allow a MITM attack to occur
I get the point, though perhaps the phrasing could do with a little less victim-shaming. How many of the times you were MITMed did you allow that to happen? Now count cases about which you still don’t know.
> Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them.
To me, secret management on the side of an unsophisticated user is arguably of more worry than someone breaking into GitHub and stealing PATs.
Consider if a user is casually contributing to documentation on GitHub using some Git client which forces them to supply an SSH key for authentication. Now there is more than one way things could go wrong, for example:
1) They use a key without a passphrase, and it is stored somewhere on their filesystem (perhaps under ~/.ssh, where ssh-keygen wants to place it by default) where any app with disk access can read it. Voila, a third party gets full access to their GitHub repositories.
2) They use a weak passphrase, reuse an old password for passphrase, or store the passphrase in plain text. Similar liability.
Meanwhile, PAT is: long, auto-generated by GitHub (so one can’t reuse a password), shown only once, doesn’t make sense for the user to save, and the client can make sure to store it using a sound mechanism (e.g., Keychain on macOS).
That said, a well-behaved user-friendly Git client could neutralize some of the downsides by taking care of generating a completely new, passphrase-protected SSH keypair under the hood, storing the passphrase and the private part reliably, and asking the user to add the public part to their GitHub account, each time it is set up on a new machine. I wonder how many clients go to such lengths.
Right, so, with a lot of extra hoop jumping GitHub have been able to special case HTTPS authentication for their site so that if you use these tokens it's only somewhat worse than what you get out of the box with SSH.
>What you need to do today: For developers, if you are using a password to authenticate Git operations with GitHub.com today, you must begin using a personal access token over HTTPS (recommended) or SSH key by August 13, 2021, to avoid disruption.
What you describe is a problem the organization has created for themselves. If they can't also come up with a solution for themselves, well, that's their problem, I guess. Stupid hurts.
As long as they're only shooting themselves with the nailgun and no one else, I'm fine with 'em doing it. Hell, I'd probably show 'em how to load it.
--
Pro-tip:
$ ssh -T -p 443 git@ssh.github.com#! /usr/bin/env sh
ssh-add ~/.ssh/id_github
ssh-add ~/.ssh/id_github2
or something like that and then just name it sshadd on the path
or create an alias in your login script
alias sshadd="ssh-add ~/.ssh/id_github && ssh-add ~/.ssh/id_github2"
I haven't actually tried it yet myself, but I think my preference would be to set the "IdentityFile" option to an environment variable (i.e., "${SSH_IDENTITYFILE}") in my ~/.ssh/config file, within an explicit "Host" definition for "github.com").
In my shell initialization files, I'd set $SSH_IDENTITYFILE to either "%d/.ssh/id_ed25519_github_personal" or "%d/.ssh/id_ed25519_github_work" (for example), depending on which I wanted to be the default.
When I wanted to use the other account, all I would need to do would be change which of the keys $SSH_IDENTITYFILE pointed to.
--
Pro-tip: you'll also want to set "ControlPath none" and "IdentitiesOnly yes" for "Host github.com".
You can't create an SSH key with select role permissions like you can with a Personal Access Token. But you do need a PAT to use the API. So you can either have one PAT + one SSH key, or just use one PAT and no SSH key. (Or multiple PATs, for fine-grained access control)
If you use multiple SSH keys in GitHub (which you should be, to access different things) then you have to manually juggle which SSH key you're passing when you pull each repo, because GitHub will just take the first SSH key you have in your ssh-agent that has an account in GitHub. You won't know from looking at a Git URI ("ssh://git@github.com") which one is needed. OTOH, with PAT, you can either make a URL like ("https://user@github.com") to pre-specify which user to use, or use "https://github.com" and specify user and PAT at auth time.
Authentication using SSH requires first accepting the host keys of Github.com, which can rotate, so you have to decide if you're going to bake the host keys into a container, or require a user to accept them (and know when they change if it's a real GitHub key change or a hacker). Or ignore host keys and lose all the security of SSH encryption. The alternative, HTTPS + PAT, requires no such operations, carries less risk, and is less work to implement.
And of course some networks block port 22.
A mistake lots of people make in this case though is they don't set IdentitiesOnly (in OpenSSH). IdentitiesOnly tells SSH that even if it knows how to authenticate as, say, 'me', if you've told it to authenticate as 'employee' in a particular configuration it should insist on only authenticating as 'employee' never 'me'. If you don't do that you can get confusing behaviour (and of course a privacy hole) on GitHub if your SSH agent knows your 'me' credentials and you try to use an account set to 'employee' credentials, as it uses the wrong ones.
The ssh-keygen manpage has a section under the heading CERTIFICATES that describes the permissions that are configurable when generating the certificate (though those permissions are ssh specific as opposed to the permissions for API access).
1. your private key requires a passphrase to decrypt
or
2. Github could be configured to require both the private ssh key as well as a username and password to authenticate
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
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?
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.
In the cloud the traditional embrace, extend and extinguish business plan becomes embrace, extend and extort.
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.
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.
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 ;=)