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.
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.”
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.
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-permissi...). No one even acknowledges this persons suggestion, even though it seems to be precisely what Github is trying to communicate.
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.
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.
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).
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.
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.
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.
Seems like a great idea except for the fact that it's for such a limited time (7am-10am and 4pm-7pm UTC on two days). Some timezones won't see these at all during working hours.
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.
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)
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 -- among the many other projects that have actively changed black/white to block/allow and other variations.
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.
I agree on more descriptive language. Sounds like then "blockout" or "password authentication blockout" would be the better language than "brownout", since that's what they're doing, blocking password auth.
The thing about a "brownout" is that service goes away, and then it comes back - for a while.
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.
> The thing about a "brownout" is that service goes away, and then it comes back - for a while.
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.
Personal Access Tokens provide both simpler and better security controls than SSH, so you end up using them in enterprises.
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.
You can configure SSH and Git to use separate keys if that's what you want (although for many people I'd recommend separating far more e.g. if you have work credentials and personal credentials, don't just segment GitHub, run everything on separate physical hardware, or at least a VM)
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.
> You can't create an SSH key with select role permissions like you can with a Personal Access Token.
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).
Even in the originally linked article, they recommend HTTPS over 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.
Some enterprises may not be able to, such as those that block SSH ports, including the alternative non-22 port that Github hosts. Yes, that can also include enterprises who contribute to open source on Github yet block port 22 network wide. It's silly.
If you'd like to, you can shoot yourself in the head repeatedly with a nailgun. Don't expect any sympathy from me afterwards, however, when you're whining about how bad your head hurts.
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.
One use case: you cannot link the same ssh-key to multiple github accounts. I have my personal and work projects on the same machine, and to get around this issue I use https authentication for one of the accounts.
There's a few ways to try to "workaround" this issue, typically involving multiple "Host" entries in ~/.ssh/config.
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".
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.
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.
I don’t mean using SSH without keys (?), I mean why use SSH instead of HTTPS?
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.
Because SSH actually delivers appropriate user security?
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.
SSH authentication is a public key authentication so:
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.
> 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).
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
> 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 ;=)
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...