GitHub Sponsors is out of beta for developers with a bank account in any of the 30 countries supported by Stripe.
For folks with bank accounts outside of that list, GitHub Sponsors is still in beta, we're accepting applications, and we’ll continue to roll out general availability to those countries in the coming months.
It's not obvious that somehow out of beta means mandatory Stripe Connect and no wire transfer. Although I assume that perhaps you use Stripe for wire transfers too?
We do support ACH transfer and wire transfer (as noted in the documentation) for developers with bank accounts in countries that are still in the limited beta. In the coming months, we'll be expanding general availability for more countries on a rolling basis. I'll look into clarifying that in the help docs too.
I think people are looking to closely at the first degree attack -- a trusted partner is pwned. If this is the case, there's far more interesting things an attacker could do. It's not too hard to envision a scenario where an attacker does not have access to embeded assets, but does have access to logs.
1. You include a script such a TypeKit. The typekit deliverable itself is not owned, but bad actors have access to typekit.com logs.
2. You use a smaller third party add on service that itself uses a logging service such as PaperTrail. PaperTrail is hacked, providing attackers access to logs.
3. You reference no external assets, but your site contains external links in the footer. Users click the navigation links rather than completing the form. You have leaked the token to whatever site that is. You are at the mercy of their log storage. YES, this does actually happen. User's click crazy things.
As I mention in the article and in other comments here: this is not likely to be exploited. Fixes, however, are not too difficult. Even adding the not-quiet-fully-supported `meta` tag to your head is a good start.
If I read this article today, I'd think, "That's interesting. let me make a note to check that out." It's not a hair-on-fire security situation, but it's not "not a problem at all" either.
In my experience, password reset tokens are not single use. They are good for both loading the form and submitting the form. They are not invalidated until the form is submitted with the new password.
They are good for 1 password reset, not 1 page load. It's possible to make them good for 1 page load, but most I've encountered are not due to the tradeoffs that would involve (see other discussions).
This has been suggested numerous time since I published. I had not previously considered this solution and I think it's a fine solution for people to make if they know the tradeoffs.
It's worth noting there are a number of reasons this JavaScript could possibly not execute beyond people who have JS turned off. I've seen a number of sites fail to execute JavaScript when an Ad Blocker is run, for instance.
In this case, there are a number of server side fixes available that wouldn't require any JavaScript. They're not terribly complicated and will always work. For that reason, I'm still comfortable with the server side fix, but think the JS fix is a decent alternative.
Depends on how the reset behaves. Some resets log you in immediately after providing a new password. Some require you to log in after resetting the password.
I feel like I've seen more of the former than the latter.
I'd certainly consider this for some applications. It depends on the value of what you are protecting. For some sites and users, the error rate introduced by this method would be unacceptable.
This requires non-idempotent get requests as you must invalidate the token on get.
I did consider this approach for Clearance and intended to go with it, but was discouraged from doing so after hearing reports that some enterprise email AV does things like open some links in emails.
There is also the user experience concern that a click the link in my email, do something else, then click the link again, having forgotten I already clicked the link. Now I'd have to re-request again.
Also, this approach is impossible if you use HMAC tokens.
I don't think anyone who opts for this approach is wrong but like most things, it's a tradeoff.
I might not be using the right term here, but the general idea is that you create an encrypted token out of some data and verify that the data is unchanged and still valid on the server. In that way you can provide a token that ensures the user had access to the link you sent them, but you don't have to store it in the database.
That should definitely happen anyway but, as the article points out, that leaves a window of time between the user clicking the link in their email and them completing the form. It might be a very brief window, but it's still exploitable (and it won't always be brief - consider a user clicking the link in their email, leaving their desk for 5 minutes or going to make a cup of tea...)
Not to mention the users that will request a reset but then remember, or forget to follow up with the reset (which I myself have been guilty of in the past).
For folks with bank accounts outside of that list, GitHub Sponsors is still in beta, we're accepting applications, and we’ll continue to roll out general availability to those countries in the coming months.