Live data from Hacker News

GitHub Has a Permission Problem

games.greggman.com

71–80 of 130 posts

Re: GitHub Has a Permission Problem

#71
post #55

Earlier quoted context omitted.

> the money just flies right out. And then flies right back in once you report the fraud. The system works not by making it hard to steal money, but by making it easy to get back. This is like credit cards... yes, a shady store can steal money from you.... but then you get it back and they go to jail.

> The system works not by making it hard to steal money, but by making it easy to get back. In other countries the system works by making it hard to steal money: I'm in New Zealand, and you can't do really anything with my account number, except pay me. Direct debit does exist, but it's a lot harder to setup (I have to send the bank original signed documents if I want to setup a direct debit from my account) to the p…

We still have junk like PoLi [1] which asks you for your internet banking credentials, and government departments use this.

I'm looking at you, NZTA.

Can't wait for the PaymentsNZ [2] effort to be fully implemented and widely adopted, so I can finally use real APIs to access this data, with low privilege throwaway tokens.

[1] https://www.polipay.co.nz

[2] https://www.apicentre.paymentsnz.co.nz

Re: GitHub Has a Permission Problem

#73
post #11

This is obviously a subject the author cares passionately about, because the article uses a lot of exclamation marks. But this tidbit struck me as hilariously out of touch: > Let's imagine your bank let you sign in to 3rd party services in a similar manner. How many people would click through on "Let ACME corp act on your behalf on your Citibank Account". I think most people would be super scared of permissions like…

It's even worse than the HTML scraping. Banks will do literally anything if the instructions arrive by fax or mail, assuming you get the account number correct. The practical security of banking is ridiculously bad.

Re: GitHub Has a Permission Problem

#74
We use GitHub as a push only destination. i.e. We never pull from it, and we never deploy from it. Our master repos are internal and don't have an upstream. This ensures that our source code is secure. Code that doesn't need to be accessible to the public, isn't pushed to GitHub at all.

Re: GitHub Has a Permission Problem

#75

Earlier quoted context omitted.

The actual money movement “API” is by far the scarier part of this. Any entity you’ve ever paid has your account number, and that’s all they need to pull more money. People talk about this like your online banking password is protecting your money... it’s not. If someone adds an online bill pay recipient from the web portal it triggers loud and slow verifications and confirmations. If someone submits an ACH transacti…

It's not, though. The legal system, and your bank will protect you in this scenario. You would report the fraud, and you would get your money back. In the case of plaid almost every bank has somewhere in their terms of service that you are responsible for protecting your online banking password, and they are not liable if you have a loss as a result of a third party getting your password from you. Which means if Plai…

It could still be a lot better though. For example, there could be an oauth-like flow where you confirm to your bank that you authorize paying the merchant the amount listed. It seems like banks would be motivated to have something like that since it would reduce the chances of them having to pay out for fraud.

Re: GitHub Has a Permission Problem

#76

I was hoping this was about gists being publicly accessible even when they are private...

Is that true? Do you have a source for that?

If you try to make a gist you'll have the option of either "Create a secret gist: secret gists are hidden from search engines but visible to anyone you give the url to" or "Create a public gist: Public gists are visible to everyone"

Parent seems to have confused "private" and "secret".

Re: GitHub Has a Permission Problem

#77
The biggest omission IMHO are project-scoped access tokens. GitLab has them above the bronze tier [1]. GitHub only has Personal Access Tokens, which grant access to all projects accessible to the user - scary!

Having project-scoped tokens would open up GH as a storage layer for personal data apps as well. Like a bookmarking app that syncs to your GitHub.

1: https://docs.gitlab.com/ee/user/project/settings/project_acc...

Re: GitHub Has a Permission Problem

#78
Indeed. GitHub recognized this and allows security settings on orgs you're a member of (such as employers, clients, et c) to opt out of users' oauthing to random third parties (wrt access to that org's info). If you're a organization, you can whitelist the apps that users are allowed to use to access your org's code.

Then, when your devs log into whatever with GitHub, they're not forking over (access to) your org's source code to every random website.

Re: GitHub Has a Permission Problem

#79
post #69

Earlier quoted context omitted.

Right, and that is why I kinda prefer the American system.... it is very easy to use and set up direct deposit and direct payments, and most of the time nothing bad happens. The few times something bad happens, it is fixed. I'd rather take the occasional having to wait a few days to sort out a fraud charge than have to be inconvenienced every time I want to send or receive money.

> I'd rather take the occasional having to wait a few days to sort out a fraud charge than have to be inconvenienced every time I want to send or receive money. Bank of New Zealand online banking doesnt seem that inconvenient, or different, from the American system. add payee, enter amount, click pay then confirm. https://www.bnz.co.nz/support/internet-banking/payments/addi...

Right, but my power bill, for example, is variable and I don’t want to have to manually pay it every month.

Re: GitHub Has a Permission Problem

#80
post #75

Earlier quoted context omitted.

It's not, though. The legal system, and your bank will protect you in this scenario. You would report the fraud, and you would get your money back. In the case of plaid almost every bank has somewhere in their terms of service that you are responsible for protecting your online banking password, and they are not liable if you have a loss as a result of a third party getting your password from you. Which means if Plai…

It could still be a lot better though. For example, there could be an oauth-like flow where you confirm to your bank that you authorize paying the merchant the amount listed. It seems like banks would be motivated to have something like that since it would reduce the chances of them having to pay out for fraud.

Unauthenticated credit/debit transfers are a pretty uniquely American thing. Many other countries have bank transfers that require the customer to authorize it (either ahead of time, or synchronously during the transaction, as you describe) before the money moves.
Post reply on HN