It's not enough that the user gives an app permission to act on my behalf, the issuer (in this case github) also has to give the app permission to ask for these scopes in the first place.

Github definitively messed up in giving the nopecha app permission to ask users for permission to star on their behalf.

If stars are important enough for them to ban users over, they should be very careful about letting third party apps request this scope from their users.

[1] public_repo: Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories. (https://docs.github.com/en/developers/apps/building-oauth-ap...)

So I do think github is broken here in a way that predictably leads to problems like above. They need better more granular scopes (and have for years; I don't understand why with their resources they haven't prioritized it), and then they need a better UI for making sure the user understands what they are granting, differentiating between read vs write, etc.

Without that... it's only a matter of time until something much worse happens, like someone abuses a scope to insert malware in someone else's repo. I would not be surprised if it's happened already but hasn't been publicly known.

BUT, also... you sign up for a service that will for-pay get around captchas for you so you can automate access to a site where the captchas are intended to prevent automated access, and then you're just shocked that this service would do something unethical...

I'm surprised this hasn't been used for malicious purposes until now.

While sure it isn't immediately expected to access "stars" feature when you give public repo access...

...you're giving it fucking repo access. That's WAY more (on a "how bad it can be if you get hacked") permissions than just starring.

What the hell, imagine logging-in with your account, you as a maintainer of a large public repo, and failing to understand clearly that you are giving a 3rd party the possibility of commiting on your behalf.

Seriously there should be a big red warning on all scopes apart from the "none" one.

Github's responsibility is to ask consent to the user and display all the requested permissions. If the user accepts then Github has done its work.

This is how all oidc providers work.

If the screen to give a 3rd party permission to identify you, looks like the screen to give a 3rd party sweeping permission to act on your behalf, that's github's responsibility and problem.

It would also be a good reason for responsible 3rd parties to ditch github for identity, if they don't address it.

(Another matter is that the big public OIDC providers' eagerness to let you use them might be a lot about tracking.)

See the latest draft for OAuth Rich Authorization Requests (“work in progress”): https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html

edit: you might be mixing up / conflating Open Authorization (an authorization standard - authorization scopes are in scope) with Open Identity (an authentication standard - authorization scopes are out of scope)

edit 2: It probably doesn’t help disambiguate which auth is which when the same company is providing both the authentication service and the authorization service.

Yes, of course OAuth is about scopes! But OIDC is a protocol built on top of OAuth2 which is for identity only. You get no permission to act on the user's behalf from the OICD scopes, only read access to information you need to identify them.

This whole problem only happened because

1. Github is an OIDC provider, allowing you to identify yourself to websites around the world.

2. Github ALSO uses OAuth2 to delegate permissions to the user's stuff on their own site.

3. The one looks too much like the other. OP probably thought he was just showing ID, but what he was doing was giving the site sweeping permission to act on his behalf, which the site promptly misused.

The problem here starts already at 2. That anyone can create an integration and ask for OICD scopes, is one thing, but why do they make it so easy to hand out their own scopes? There are not that many third party apps that have a legitimate need to act on the user's behalf. Maybe some continuous integration stuff? But even that should only have access to the user's own repositories. Nothing I can think of has a legitimate need to go around starring random repositories.

That was probably one of the advantages of shoe-horning authentication (OpenID) with the existing authorization standard (OAuth).

> Why is everyone linking this draft? It's got very little to do with what we're discussing.

> … Github ALSO uses OAuth2 to delegate permissions to the user's stuff on their own site

> … But even that should only have access to the user’s own repositories.

Seems like Rich Authorization Requests are exactly what we are discussing.

Give it a skim (or a read).

This is not very fine-grained. It would be perfectly possible to gate access to social features of github (such as starring) behind a plain old scope. Distinguishing "access to all your own repositories" from "access to anything else on github, as you" also is not a fine-grained difference.

(Imagine if e-mail adresses were considered "invalid" in forms if not from Gmail or Outlook !)

It was especially bad with last years Advent of Code, where going through OpenID (or was it OAuth ?) was the ONLY way to join, and with only 3 options listed, none of which I wanted to use !

So an app could request only the non-data-access OIDC scope, or an IdP could enforce that it only allows apps the OIDC info.

On top of that is the user consent. What has been pointed out in threads here is that the IdPs are making the UX for basic OIDC consent too similar to the UX for consenting to privileged data access.

And of course if an oauth token is being abused, the IdP should ban the client app first, not the user...

It is good to take a step back from the tech and think about it from the user's perspective.

No. When an app is registered with them, a provider does check if the scopes requested have a reasonable business purpose. Many registration forms even ask you to explain why you need the scopes requested. This is similar to how Apple App store does review.

Many OAuth providers also check periodically if one of their registered apps is used for any pattern of abuse.

GitHub isn’t doing the handing out, it is the user doing the handing out.

I don’t blame the user, as a rule, but in this type of scenario, the user (a consumer of development tools) shouldn’t be excused, in my opinion.

This would be like a doctor complaining for getting sued for malpractice by a patient of a nurse under the doctor, while the doctor neglected to review the patient chart and neglected to take the time to speak with the nurse.

caveat emptor

All that said, I would hope that bad actors that get caught, effectively phishing for GitHub credentials, using a technique like this end up being banned from GitHub.

I have written some integrations against altinn, the Norwegian government's portal for basically anything official. Getting approval for a scope there is a process, as well it should be. If I write an app that lets users send construction applications to the local municipality on the user's behalf, do you think I can just sneak in a request for permission to change the user's address, name and bank account registrations as well? No. There are scopes for that (I assume), but my app won't get to request them, no matter how much the user would be willing to give them.

And "caveat emptor" is not the threat model you can get away with on the web. Sure, it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials. But I'm a user too, and it would NOT be fun as a user.

Caveat emptor is not a threat model, it is a risk mitigation.

It is arguably the only mitigation directly in the hands of the consumer.

And that the modern phrase is from a 2000+ year old “dead language” should certainly speak to the longevity, utility, and effectiveness of that mitigation.

> it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials

thankfully there are standards and RFC’s that indicate best practices that recommend that these security risks be considered and mitigated

edit: see Rich Authorization Requests <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html> for the “work in progress”

If not, you won't keep them. They will leave. And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".

Nothing but agreement there.

Can you identify a specific recommendation by the IETF or W3C that was ignored, in this case?

> And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".

I had to look up that apparent reference to Harry Potter, but I disagree.

Educating your users about phishing risks, aka “caveat emptor” in this context, is explicitly a best practice for mitigating these kinds of security risks on the open web.

Furthermore, the audience of Github is decidedly more technical than a government website or social media platforms. IMHO it can be expected that its users step through authentication flows a bit more carefully.

Github should act more decisive when applications turn out to be malicious though. The Laissez-faire policy of frictionless integration of applications has to be balanced with effective procedures to react to malicious uses.

Let alone banning the user instead of the client app...

It's a choice to be at such scale that github cannot validate 3rd party auth. Gothub should accept fault for these incidents if they are not going to validate their partners.

It's the exact same as third party sellers shipping counterfeits on Amazon. Choosing to achieve massive scale leaves quality, validation, and consumer protection behind.

Similarly we shouldn't bill for service accounts, especially when they're documented as the way to limit API token access. It's self-defeatist like taxing longer passwords.

Therefore if you want them, pay up or do it yourself.

They exist for github apps, and they're being rolled out for PATs alongside forced expiration: https://github.blog/2022-10-18-introducing-fine-grained-pers...

Not sure there's any way for them to happen for oauth apps though. And even if they do, they're opt-in for the app and the old broad scope will remain. At best the broad scopes would only be accessible to old apps grandfathered in but that ain't much (there's probably a billion abandoned oauth applications you could purchase for that grandfathering).

$x/mo * Service accounts is dumb.

Sorry, hard disagree. You have responsibility, here. We all do. Be extremely wary of what privileges you are giving away, and do not hesitate to forgo sign-in when the privileges are unreasonable.

Why would anyone click "yes" to a random site that wants control over their Github starring privileges without a clear explanation as to what they will be using it for?

We can excuse the naïve, but this is a tech-related site. If you don't know, now you know.

GitHub is taking the “ban them all and let God sort ‘em out” approach to figuring out if OP is telling the truth.

Otherwise it would be quite simple to write a malbot and then claim innocence because it was the bot doing it, not me.

I think the approach to automation is best when the authority and responsibility always ties back to an individual or group.

I automatically decline the moment I see any app trying to authorize with that scope.

Nonetheless, perhaps this is pointing to Microsoft’s Window’s UAC moment for GitHub.

Bright yellow or red UX with warnings that if you click “agree” then you might as well have given away your computer to a malicious actor.

We keep asking that users must be asked for explicit permissions and granular scopes are for the good and then users themselves skip reading on these permission grants.

Github has always (in my experience) been clear about what permissions are being granted to the site you're signing into, and if you don't agree, you can easily cancel the sign-on flow.

An example requesting the 'public_repo' scope (the client_id is a random one from the internet): https://github.com/login/oauth/authorize?client_id=33a703d01...

No one should be surprised that allowing an untrusted program to write files and permissions through an operating system could lead to a security exploit.

Many would likely be cognizant of the risk of becoming a member of a botnet.

Allowing untrusted programs to control your digital services is not fundamentally different, in my current perspective.

What I would not expect is Github banning me in some misplaced form of victim blaming.

Your GitHub user account was compromised by a bad actor, so it shouldn’t be surprising nor considered victim blaming.

Of course, GitHub might cross the line to being unreasonable if they become aware of this as a potential security issue and fail to mitigate the phishing risks that they are exposing their customers to.

edit: restoring your user account to good standing, if absolutely necessary, is certainly something to strive for, but be aware that it can take years or never, from anecdotes that I’ve heard about Google, Apple, Twitter, etc. Microsoft/GitHub/LinkedIn won’t likely be any different, in that regard

But GitHub sees where did the request to create the stars come from. The requests all came with authentication tokens associated with the given malicious site. They have all the data to see how the account got “compromised”, and they also can see that the account owner is unlikely to have knowingly participated in the “star farming”.[1]

The obvious and correct solution is to delete all stars created through tokens associated with the malicious site[2], disable access for the malicious site and write a letter to the compromised users.

1: further absurdity is that by deciding that the stars were farmed Github already made the decision that they are not comming organically from users. Because if they were comming organically from the users then it wouldn’t be star farming, just a popular repo. So why are they punishing the users then?

2: one more absurdity is that stars don’t cost github anything. It is just a number in a DB. It is not like they incurred a cost due to this attack. Github decided that they care about some stupid stars, and make the farming of them a bannable offense.

You can blame the person handing out the wallet for being naive, but ultimately the bad actor is the other.

No one lies on the internet? Those Nigerian princes are very clear what they are going to do with the money you send them, but it doesn't make it true. Providing 3rd party access to an account should come with over sight abilities.

I'm going by what the guy wrote. He "clicked through a bunch of pages". If you "click through a bunch of pages" and get scammed, you suffer consequences. Play stupid games, win stupid prizes.

The whole story is suss, tho.

It's great when you can get a test account for this, but often companies will simply tell you "create a throw away account and test there" (ex: google does this).

That's not malicious - I'm well within my terms of service - I'm not doing anything with the service other than ensuring that behavior that is not contractually guaranteed still works (because unlike an API, most sites change their DOM often and with no warning).

It's not something I can fake with self-hosted content or mocks, because my version won't change when their DOM does.

---

I've investigated captcha solutions for this exact reason. Not to mention ways to automate 2fa. I understand the overlap with malicious intent here, but just because there is overlap does not imply that OP was malicious.

I’m sorry which rule covers that?

>Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community. Edit out swipes.

>Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

>When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

https://news.ycombinator.com/newsguidelines.html

None of the cursing is directed at the person, but the topic under discussion. At no point have I cursed at him, or even been snarky to him. I have used emphatic language outside of a formal setting.

Personally - the existence of a curse word alone is not enough to invalidate an argument.

And in this case - it reflects my true opinion on the topic: It's bullshit to blame the user here, when the tech exists precisely to allow more accurate determinations of cause. It literally exists to prevent EXACTLY the sort of grey area the commenter above me seems to take for granted. I absolutely should be able to allow an oauth app to interact with a service and not be held accountable for malicious actions of that app if the actions are the result of abuse by the app and not my intent.

Otherwise why fucking bother with the rigmarole of the oauth app registration in the first place? Just hand the user a personal access token and let them plug it in where ever they'd like if you're going to ban them anyways...

"Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community. Edit out swipes."

If you didn't want them starred you shouldn't have given the site permission to star

Legally they might be in the right, but punishing victims of social engineering further doesn't seem like a fair or smart business decision.

Suppose there is a service which allows you to watch free porn videos as long as you hand over permissions to star a bunch of repos using your account. Clearly, the service is abusive and should be banned. But isn't it also quite fair for Github to penalize the users? They knew they were handing over something of value when they authorized the access. Either they chose to exchange their genuine 'Github clout' for something they wanted, or their accounts are spammy in the first place (for example, if they created an account solely to access that service).

However, what you won’t see in a standard SSO flow is anything along the lines of “GitHub will be able to star repositories on your behalf.” If you’re seeing those kind of messages, you aren’t doing a minimal SSO flow (just having GH vouch for your identity), you’re granting access to a 3rd party to do things with your GH account.

"public_repo Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories."

This is accurate, but oauth2 is the standard sign in with GitHub. oauth is literally designed as an authorisation mechanism to allow people to do things on your behalf, the ability to authorise access was later repurposed into an authentication mechanism.

However, getting banned is pretty minor compared to the other bad things that can happen if you grant sketchy websites access to your accounts without reading what you’re granting.

Sorry I'm somone else but I'd just go and assume it was because they are human, not a terminator, and their eyes do not have an integrated HUD talking with GitHub's backend with status indicators showing each currently authenticated account??? You want this kind of correctness you have to write software in Rust or something. "You're holding it wrong" lol

Yes, you are supposed to read the dialogs. OP really got got, and that sucks. But it's literally why that permissions checklist step - that they ignored - exists.

If the same happens to me I'm positive I'm /punching the screen, locating whoever set that bullshit up and taking a dump into their physical mailbox./

None of those things are an excuse. The dialog is there as a gateway to protect your data and GitHub's platform from the third party. If you're not going to review a clear dialog describing the permissions, then there is nothing that GitHub can do, other than decide that you cannot be trusted with this responsibility.

Also, drunk and high? You chose to be in those states. If you can't make the decision correctly in whatever state you currently are, then shouldn't be making decisions in that state. Take some responsibility for yourself.

I don't really believe you "choose to be in states", what an absurd way to think about the behavior of hairless apes. Sorry but I will continue having the illusion of making decisions in whatever state I please. What now?

Maybe have some kids or smoke a joint because you're going to end up in a looney bin with this kind of expectations towards your fellow idiot humans

> smoke a joint Done that. Didn't use it as an excuse.

> What now? Consequences don't care about your defiance. Nor should GitHub or whatever party has to deal with you.

Normal people make mistakes. Decent people care about limiting the damage to others. Assholes blame everybody else and deny all responsibility.

But that's getting a bit off track. I responded to the attitude where someone should not be expected to read a simple and clear dialog because they were a hairless ape that could be drunk.

FINALLY you said something reasonable :-D I'm sorry for being an idiot, I wanted to give a different perspective, I guess I'm passionate about nice and human UI. What happened to OP is what I call a Huge Dick Move. I will defend them to the grave because I like to cut people a big big piece of slack. Because yeah they could be drunk, or just tired, which is cool, you know.

What's not cool at all though is so called "engineers" ebgineering shit like OP described which makes me ashamed of my profession everytime I watch my grandpa painstakingly wade through crap like this all the time.

I will cope, I'm a dev, many people will not and there goes their UX. Straight to trash \o/

I don't want to get absolved of my responsibilities or whatever, I want UI that doesn't suck dick and ideally doesn't star 500 repos by itself

when was i already logged in? there was only 1 action of "sign in with github". thats it

We at least/even have OIDC for that now.

Also, seems like you’re probably a developer? If so, SSO, OAuth2, OIDC, etc. are worth learning about. You seem to be confusing/conflating SSO and OAuth2 authorization code flows, when they’re reasonably different things.

That said GitHub should have banned that website for lying and abusing instead of OP.

It makes a possibly dodgy website look more secure and legit by using a well known provider like Github for the login process.

In addition, it potentially exposes data from that well known provider, which is often sensitive data, as in the case of Github.

Or maybe I shouldn't just take everything at face value and pay attention to what I'm doing.

What is strange is that you are banned for an action someone else took. That doesn’t make any sense.

I'll honestly never get that point of view: it's an evolutionary disadvantage to not fall for these kinds of attacks. Our intelligence is largely predicated on how easily we can pattern match and filter out "excess" information.

So OP being bombarded with a list of harmless permissions along with one deceptively dangerous one (deceptive because they wouldn't expect to lead to being pwn'd anyways, since it's stars) and granting is not being sloppy, it's being an intelligent person.

Github is large enough to have UX experts who know this stuff, and at the very least if stars are grounds for being banned, they should be grouping it with dangerous permissions and using more confirmations.

And even better... they should just rate limit starring! How often is someone going to star 500 of someone's repos legitimately that rate limiting would ruin everyone's day?

And you're ready to hand over even the first 3 items there, you're not likely to assume or even notice that github stars about to get you knocked out of orbit.

I know this is a place of hubris but it almost comes across as a strange lack of self-awareness that this many people actually think they'd have caught that.

No, that is being an intelligent ape reacting to a twitching bush by running up a tree on the chance that a predator is behind the bush. The tables have turned since then. Back then the analytical ape would have gotten eaten and not passed his genes on, but there is no longer a biological imperative to mindlessly react to things.

Modern humanity hasn't existed for an eye blink compared to the everything that led up til now, so there's two kinds of people:

- People who understand we all have these blind spots and understand account for them

- People who don't even realize how often they run into these blind spot.

You're much better off learning to be the former, but I'm sure it feels good to proclaim from on high how you're just sloppy for not checking every dialog you come across...

- People who've heard about about the marshmallow impulse control study + the effects that medieval-plagues/cousin-marriage has had on the human gene pool

- People who say silly things like "Modern humanity hasn't existed for an eye blink compared to.."

You're much better off reading a long term study on the life trajectories of people who had their impulse control quantified as children - spoiler: they do not do well in the modern world relative to everyone else enjoying a reduced probability of incarceration.

Intelligent apes surrounded by wiggling bushes stop paying attention to wiggling bushes and get munched on by a predator eventually, no?

Agreed, but unlike a login prompt, those things are there for the benefit of others - not you. To continue the analogy: blowing through a login (or changing traffic signal, regardless of color) is like an ape exposing his belly to any silhouette vaguely shaped like a trusted member of the troop.

> ..stop paying attention to wiggling bushes..

Dunno, he could also have a breakdown - lab rats are known to practically lay down and die when you suddenly reverse the role of external stimuli in a system of punishment and reward. But I don't see how that fits here, the user isn't being plagued by nonsensical login prompts constantly springing into existence.