maltfield

joined 2 years ago
sorted by: new top controversial old
Why OAuth MUST share access token with 3rd party?!? in c/[email protected]
[–] [email protected] 1 points 3 months ago (1 children)

That's bad.

OAuth supports several types of flows. If I'm not mistaken (I've learned a bit more about OAuth since yesterday) you're describing the Authorization Code Flow -- as documented in RFC 6749 (The OAuth 2.0 Authorization Framework), Section 4.1 (Authorization Code Grant):

That RFC defines many other types of flows that do not require sharing the access keys with a third party, such as the Client Credentials Flow, as documented in RFC 6749 Section 4.4 (Client Credentials Grant):

The only reason you'd want to use the Authorization Code Flow is if the third party needs your access token for some reason, or if you want to hide the access key from the user agent.

The problem here is that Stripe is using the wrong flow (the third party doesn't need the access token, as they claim they never save it anyway). And if keyCloak only supports that one flow, that's would be a problem too (in this case).

Why OAuth MUST share access token with 3rd party?!? in c/[email protected]
[–] [email protected] 2 points 3 months ago* (last edited 3 months ago)

Upon further reading of RFC 6749, it appears that OAuth does require this -- sometimes.

It depends on the OAuth Flow. In this case, Stripe uses the “Authorization Code” Grant.

This is documented in Stripe’s OAuth reference documentation here:

curl https://connect.stripe.com/oauth/token \
  -u sk_test_MgvkTWK1jRG3olSRx9B7Mmxo: \
  -d “code”=”ac_123456789” \
  -d “grant_type”=”authorization_code”

Authorization Code Grants are defined in RFC 6749 (The OAuth 2.0 Authorization Framework), Section 4.1 (Authorization Code Grant):

To better understand why the OAuth Authorization Code Grant requires sharing the access token with a thrid party server, I found this article (Common OAuth Vulnerabilities) by Doyensec very elucidating:

It says that the Authorization Code Flow is supposed to be used when you don’t want to share the tokens with the user agent.

The Authorization Code Flow is one of the most widely used OAuth flows in web applications. Unlike the Implicit Flow, which requests the Access Token directly to the Authorization Server, the Authorization Code Flow introduces an intermediary step. In this process, the User Agent first retrieves an Authorization Code, which the application then exchanges, along with the Client Credentials, for an Access Token. This additional step ensures that only the Client Application has access to the Access Token, preventing the User Agent from ever seeing it.

But this doesn't make sense for this use-case. It appears Stripe is needlessly putting us at risk by choosing the Authorization Code Grant.

Why OAuth MUST share access token with 3rd party?!? in c/[email protected]
[–] [email protected] 1 points 3 months ago

Stripe Connect does not support Client Credentials flow.

Can you please tell me what is the name of the "flow" that Stripe Connect is using here?

Why OAuth MUST share access token with 3rd party?!? in c/[email protected]
[–] [email protected] 1 points 3 months ago (3 children)

I figured out the root technical cause. It's because Stripe doesn't allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that's hard-coded into the app.

For security purposes, Stripe redirects a user only to a predefined URI.

That's why Stripe forces you to expose your access tokens to the developer's servers.

I'd still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer's servers.

Why OAuth MUST share access token with 3rd party?!? in c/[email protected]
[–] [email protected] 1 points 3 months ago* (last edited 3 months ago)

It’s called the Client Credentials flow (RFC 6749, Section 4.4).

Finally someone directs me to the actual RFC. Except that section is titled "Client Credentials Grant"

Why do I see this sometimes called a "Grant" and sometimes called a "Flow"?

What's the definition and difference of each?

Why OAuth MUST share access token with 3rd party?!? in c/[email protected]
[–] [email protected] 1 points 3 months ago* (last edited 3 months ago)

Thanks, but I don't think this is the case here. The Authentication provider is Stripe (or, at least, it's a stripe.com domain name). The 3rd party is the app developer's server.

Stripe's infra is already PCI compliant.

I'm not sure how a hardware security token would be relevant here. The end result must be something-you-know access token. Initial setup is done with 2FA, sure. But I don't think the server can store (or emulate) a passkey. The issue here isn't how I authenticate with Stripe. It's after that -- when Stripe gives the tokens to the third party (the dev's server) and then the third party gives the token to my server. I don't understand why Stripe doesn't just let the devs implement it so Stripe gives the tokens directly to my server.

1
Why OAuth MUST share access token with 3rd party?!? (lemmy.ml)
 

Why does Stripe require OAuth tokens to pass through a third party server?

Can someone who understands OAuth better than me explain to me why Stripe REQUIRES that their OAuth Access Keys get shared with a third party?

I've tried RTFM, but my biggest hangup is that the OAuth docs appear describe a very different situation than mine. They usually describe a user agent (web browser) as the client. And they talk about "your users" as if I have a bunch of users that I'm going to be fetching access keys for.

Nah, this is server <--> server. I have a server. Stripe has a server. I am one user. All I need is ONE API key for ONE account. But I'm forced to use OAuth. It doesn't seem appropriate, and it's especially concerning that the "flow" requires the (non-expiring!) Access Token to be shared with a third party server. Why?!?

I recently learned that Stripe has been pushing OAuth (branded as "Stripe Connect") to its integration apps as the "more secure" solution, compared to Restricted API Keys. In fact, we've found that most integrations we've encountered that use Stripe Connect are less secure than using Restricted API Keys because the (private!) tokens are shared with a third party!

I've been using Stripe to handle credit card payments on my e-commerce website for years. Recently, we updated our wordpress e-commerce website and all its plugins. And then we discovered that all credit card payments were broken because our Stripe Payment Gateway plugin stopped allowing use of Restricted API Keys. Instead they only support "Stripe Connect" (which, afaict, is a marketing term for OAuth). This change forced us to do a security audit to make sure that the new authentication method met our org's security requirements. What we found was shocking.

So far we've started auditing two woocommerce plugins for Stripe, and both have admitted that the OAuth tokens are shared with their (the developer's) servers!

One of them is a "Stripe Verified Partner", and they told us that they're contractually obligated by Stripe to use only "Stripe Connect" (OAuth) -- they are not allowed to use good-'ol API Keys.

They also told us that Stripe REQUIRED them to include them in the OAuth flow, such that their servers are given our (very secret!) OAuth Access Keys!

The benefit of normal API Keys, of course, is that they're more secure than this OAuth setup for (at least) two reasons:

  1. I generate the API keys myself, and I can restrict the scope of the keys permissions

  2. I store the key myself on my own server. It's never transmitted-to nor stored-on any third party servers. Only my server and Stripe's servers ever see it.

Can someone shine a light onto this darkpattern? I understand that standardization is good. OAuth Refresh Keys add security (this service doesn't use them). But why-oh-why would you FORCE OAuth flows that share the (non-expiring) Access Tokens with a third party? And why would you claim that's more secure than good-ol-API-keys?

Does OAuth somehow not support server<-->server flows? Or is it a library issue?

What am I missing?

4
Why OAuth MUST share access token with 3rd party?!? (lemmy.ml)
 

Why does Stripe require OAuth tokens to pass through a third party server?

Can someone who understands OAuth better than me explain to me why Stripe REQUIRES that their OAuth Access Keys get shared with a third party?

I've tried RTFM, but my biggest hangup is that the OAuth docs appear describe a very different situation than mine. They usually describe a user agent (web browser) as the client. And they talk about "your users" as if I have a bunch of users that I'm going to be fetching access keys for.

Nah, this is server <--> server. I have a server. Stripe has a server. I am one user. All I need is ONE API key for ONE account. But I'm forced to use OAuth. It doesn't seem appropriate, and it's especially concerning that the "flow" requires the (non-expiring!) Access Token to be shared with a third party server. Why?!?

I recently learned that Stripe has been pushing OAuth (branded as "Stripe Connect") to its integration apps as the "more secure" solution, compared to Restricted API Keys. In fact, we've found that most integrations we've encountered that use Stripe Connect are less secure than using Restricted API Keys because the (private!) tokens are shared with a third party!

I've been using Stripe to handle credit card payments on my e-commerce website for years. Recently, we updated our wordpress e-commerce website and all its plugins. And then we discovered that all credit card payments were broken because our Stripe Payment Gateway plugin stopped allowing use of Restricted API Keys. Instead they only support "Stripe Connect" (which, afaict, is a marketing term for OAuth). This change forced us to do a security audit to make sure that the new authentication method met our org's security requirements. What we found was shocking.

So far we've started auditing two woocommerce plugins for Stripe, and both have admitted that the OAuth tokens are shared with their (the developer's) servers!

One of them is a "Stripe Verified Partner", and they told us that they're contractually obligated by Stripe to use only "Stripe Connect" (OAuth) -- they are not allowed to use good-'ol API Keys.

They also told us that Stripe REQUIRED them to include them in the OAuth flow, such that their servers are given our (very secret!) OAuth Access Keys!

The benefit of normal API Keys, of course, is that they're more secure than this OAuth setup for (at least) two reasons:

  1. I generate the API keys myself, and I can restrict the scope of the keys permissions

  2. I store the key myself on my own server. It's never transmitted-to nor stored-on any third party servers. Only my server and Stripe's servers ever see it.

Can someone shine a light onto this darkpattern? I understand that standardization is good. OAuth Refresh Keys add security (this service doesn't use them). But why-oh-why would you FORCE OAuth flows that share the (non-expiring) Access Tokens with a third party? And why would you claim that's more secure than good-ol-API-keys?

Does OAuth somehow not support server<-->server flows? Or is it a library issue?

What am I missing?

2
See which instances are blocked more than others (lemmy.ml)
submitted 2 years ago* (last edited 2 years ago) by [email protected] to c/[email protected]
0 comments fedilink
 

awesome-lemmy-instances adds two new columns:

  1. BI - The number of instances that this instance blocks
  2. BB - The number of instances that block this instance

Now you can quickly see which instances censor (or are censored) in the lemmyverse:

3
Intro Guide to Lemmy (tech.michaelaltfield.net)
submitted 2 years ago* (last edited 2 years ago) by [email protected] to c/[email protected]
0 comments fedilink
 

I wrote a guide to help users with their migration to Lemmy

This guide will help new lemmy users find and subscribe-to (remote) lemmy ~~subreddits~~ communities

1
[Request] Intro to Lemmy (Video Guide) (lemmy.ml)
submitted 2 years ago* (last edited 2 years ago) by [email protected] to c/[email protected]
0 comments fedilink
 

Before reddit goes dark on Monday, I would like to add a short video to the join-lemmy.org site that shows new users how to create a lemmy account and subscribe to (remote) communities.

The video should be about 2-minutes long (shorter is better) with a screen recording and voiceover narration. If you do this, you'll get a lot of traffic to your youtube/peertube account ;)

Here's the outline of the video requested:

  1. Mention that lemmy is a federated reddit alterntaive based on ActivityPub where 'subreddits' are called 'communities'. Go to join-lemmy.org in your web browser and click the big Join a Server button.

  2. Tell the viewer that it doesn't really matter which instance they pick because you can subscribe to a 'community' from one instance from any other instance. Again reiterate that what reddit calls a 'subreddit' is called a 'community' on lemmy. Then just click Join from a random server from the "Recommended" list of instances. Tell the user to just pick one at random because it doesn't matter which they choose.

  3. Signup for an account. Tell the user they may need to wait for the account to be approved.

  4. Try logging-in. Wait some hours (for approval), if needed. Login to the account.

  5. Show the UI for ~10 seconds, then tell the user that they can browse all communities using the "Lemmy Commnity Browser" run by Feddit. Again, reiterate that what used to be called ‘subreddits’ in reddit are called ‘communities’ on lemmy, and that each lemmy instance can have many communities. Open a new browser tab going to https://browse.feddit.de/.

  6. On https://browse.feddit.de/, search for some popular community (eg documentaries) and then click the link. For the purposes of this video demo, make sure you select a “remote” community that’s hosted on an instance that’s distinct from where the user signed-up.

  7. Tell the user that there's three ways to subscribe to a remote instance: [1] Search by remote URL, [2] Search by shorthand identifier, or [3] Manually construct the URL for your instance to their instance

  8. Show copying & pasting the URL of the remote community (eg https://lemmy.ml/c/documentaries) into the search field of their own community, and then clicking on the result.

  9. Show copying & pasting the shorthand identifier for the remote community (eg [[email protected]](/c/[email protected])) into the search field of their own community, and then clicking the result.

  10. Open a new tab, and show how to manually construct the URL for the remote community in their own instance's site (eg https:///c/[email protected]) and load this page in the browser. Then click the Subscribe button

  11. Tell the user that after they've subscribed to a bunch of communities, they can click the logo of their instance on the top-left of the UI to return to the Home Page of their instance. Then they can click the "Subscribed" tab to view posts to all the communities they subscribed to across the entire fediverse.

  12. Show the changing of the sort from 'Active' to 'New' and 'Top'.

  13. Tell the user that for more information on how to use Lemmy, they can read the documentation at https://join-lemmy.org/docs/en/ or post questions to the Lemmy community on lemmy.ml (https://lemmy.ml/c/lemmy or [[email protected]](/c/[email protected])) that’s moderated by the lemmy developers.

Bonus: Tell that there's an iOS and Android app and show a quick ~5 seconds browsing in one or both.

I'm crowdsourcing this because I'm not much of a video creator, but I think this would be an incredibly useful resource to new lemmy users. And I can tell you that, if you make this video, it will drive a ton of traffic to your channel ;)

Can anyone with some video production skills help-out new lemmy users by making this short video? If you upload this to YouTube, please make sure you mark the license as Creative Commons CC-BY-SA so that we can add it to documentation and share it as widely as possible :)

1
[Request] Intro to Lemmy (Video Guide) (lemmy.ml)
 

Before reddit goes dark on Monday, I would like to add a short video to the join-lemmy.org site that shows new users how to create a lemmy account and subscribe to (remote) communities.

The video should be about 2-minutes long (shorter is better) with a screen recording and voiceover narration. If you do this, you'll get a lot of traffic to your youtube/peertube account ;)

Here's the outline of the video requested:

  1. Mention that lemmy is a federated reddit alterntaive based on ActivityPub where 'subreddits' are called 'communities'. Go to join-lemmy.org in your web browser and click the big Join a Server button.

  2. Tell the viewer that it doesn't really matter which instance they pick because you can subscribe to a 'community' from one instance from any other instance. Again reiterate that what reddit calls a 'subreddit' is called a 'community' on lemmy. Then just click Join from a random server from the "Recommended" list of instances. Tell the user to just pick one at random because it doesn't matter which they choose.

  3. Signup for an account. Tell the user they may need to wait for the account to be approved.

  4. Try logging-in. Wait some hours (for approval), if needed. Login to the account.

  5. Show the UI for ~10 seconds, then tell the user that they can browse all communities using the "Lemmy Commnity Browser" run by Feddit. Again, reiterate that what used to be called ‘subreddits’ in reddit are called ‘communities’ on lemmy, and that each lemmy instance can have many communities. Open a new browser tab going to https://browse.feddit.de/.

  6. On https://browse.feddit.de/, search for some popular community (eg documentaries) and then click the link. For the purposes of this video demo, make sure you select a “remote” community that’s hosted on an instance that’s distinct from where the user signed-up.

  7. Tell the user that there's three ways to subscribe to a remote instance: [1] Search by remote URL, [2] Search by shorthand identifier, or [3] Manually construct the URL for your instance to their instance

  8. Show copying & pasting the URL of the remote community (eg https://lemmy.ml/c/documentaries) into the search field of their own community, and then clicking on the result.

  9. Show copying & pasting the shorthand identifier for the remote community (eg [[email protected]](/c/[email protected])) into the search field of their own community, and then clicking the result.

  10. Open a new tab, and show how to manually construct the URL for the remote community in their own instance's site (eg https:///c/[email protected]) and load this page in the browser. Then click the Subscribe button

  11. Tell the user that after they've subscribed to a bunch of communities, they can click the logo of their instance on the top-left of the UI to return to the Home Page of their instance. Then they can click the "Subscribed" tab to view posts to all the communities they subscribed to across the entire fediverse.

  12. Show the changing of the sort from 'Active' to 'New' and 'Top'.

  13. Tell the user that for more information on how to use Lemmy, they can read the documentation at https://join-lemmy.org/docs/en/ or post questions to the Lemmy community on lemmy.ml (https://lemmy.ml/c/lemmy or [[email protected]](/c/[email protected])) that’s moderated by the lemmy developers.

Bonus: Tell that there's an iOS and Android app and show a quick ~5 seconds browsing in one or both.

I'm crowdsourcing this because I'm not much of a video creator, but I think this would be an incredibly useful resource to new lemmy users. And I can tell you that, if you make this video, it will drive a ton of traffic to your channel ;)

Can anyone with some video production skills help-out new lemmy users by making this short video? If you upload this to YouTube, please make sure you mark the license as Creative Commons CC-BY-SA so that we can add it to documentation and share it as widely as possible :)

1
awesome-lemmy-instances adds server uptime (github.com)
submitted 2 years ago* (last edited 2 years ago) by [email protected] to c/[email protected]
0 comments fedilink
 

The GitHub repo that provides a comparison table of different lemmy instances now includes server uptime %

Thanks to David Morley for providing this data via the Fediverse Observer API

lemmy.ml is overloaded, use other instances instead in c/[email protected]
[–] [email protected] 1 points 2 years ago

At what point do you plan to close this instance to new users?

0
[RedReader] Update 4: Reddit grants non-commercial accessibility exemption to RedReader (old.reddit.com)
 

Hello everyone, after a few days of discussions with Reddit I finally have an update to share on the current situation.

It has been agreed that RedReader falls under the exemption for non-commercial accessibility-focused apps, due to the work that has been done to optimize the app for screen readers, and the app's high level of usage within the blind community.

To summarize:

RedReader can continue to operate as a free and open source app.

There will be no ads, monetization, etc.

I still have concerns about Reddit's current trajectory, and plan to expand the range of sites RedReader is able to access in future.

Short-term plan

In the next few weeks, there are a couple of changes I need to make to the app to comply with the new developer terms:

When users first launch the app, they will be prompted to agree to Reddit's terms and conditions.

Developers other than me who compile RedReader from source will need to provide their own API keys. For individual use, these fall under Reddit's free tier.
    This change will unfortunately create an extra hurdle for contributors, so I'll do what I can to make this as simple as possible and I'll write up some instructions for this.
    Users who download the app from Google Play are unaffected by this, as those APKs are built by me.
    With F-Droid, I will continue to ensure the app is distributed there (I personally use a de-Googled phone), however this will have to be distributed from the RedReader repository rather than the official F-Droid repo (similar to the Alpha version). I'll aim to release more details on this soon, but needless to say, non-Google app distribution channels are still a big priority for me.

So for the most part, we can continue operating under the status quo. Long-term plan

While I'm grateful to them for granting the accessibility exemption, I continue to think that Reddit is making a big mistake with the broader API changes as a whole, and throughout the discussions with them I've made this clear. I think it's very reasonable to be concerned about Reddit's current trajectory, and nobody can know for sure how long the exemption will last.

I also have concerns about the treatment of other developers, particularly Christian Selig, including the dubious public claims that have been made about Apollo's efficiency.

I spent a long time thinking about whether to continue operating RedReader as a Reddit app under these circumstances, and came to the decision that the app will continue to interoperate with Reddit for the foreseeable future.

Over the last week I've been in touch with the developers of Lemmy, who indicated that they would prefer a slow ramp up of traffic rather than a sudden influx. Similarly, the major Lemmy instances are struggling under the sheer number of Reddit refugees right now.

While I hope the accessibility exemption will continue indefinitely, nobody can guarantee that it will. Even in the the worst case scenario, the exemption at least grants us some breathing room to see how the situation develops.

My long-term vision for RedReader is to restructure the app to more easily support other sites, including Lemmy, and perhaps others such as Tild.es and Hacker News. Before the API changes were announced, I was already considering adding RSS reader functionality to the app, and I think it would be cool to work with some kind of "open forum protocol" which would allow a variety of websites and apps to interoperate with each other through a uniform API.

We will continue to prioritize accessibility in the app, while also continuing to serve the userbase as a whole. Thank you

Finally, I want to thank everyone in the community for your messages of support, and the nearly 200 contributors who have written code for RedReader over the last decade.

To those who have worked so hard on RedReader's accessibility features, I'd like to offer an extra big "thank you", as without your contributions, the app wouldn't have been granted this exemption.

Despite my continuing reservations about Reddit's current direction, and regardless of what people will say about their motivations here, I am pleased that they've taken into account the fact that RedReader is free and open source, and serves a purpose for users in the blind community.

1
BusKill Warrant Canary for 2023 H2 🕵️ (buskill.in)
 

We just published our #WarrantCanary for 2023 H2 🕵️

https://buskill.in/canary-006/

Warrant Canaries are a means for us to (not) inform you of (not being) breached if served with a State-issued, secret subpoena (gag order) #infosec

1
BusKill Warrant Canary for 2023 H2 🕵️ (buskill.in)
 

We just published our #WarrantCanary for 2023 H2 🕵️

https://buskill.in/canary-006/

Warrant Canaries are a means for us to (not) inform you of (not being) breached if served with a State-issued, secret subpoena (gag order) #infosec

Which instances should be recommended on join-lemmy.org? in c/[email protected]
[–] [email protected] 0 points 2 years ago* (last edited 2 years ago)

I think we should add the following criteria to instances at the VERY TOP that are recommended to new users:

  1. The instances does not define an allowed list of instances
  2. Downvotes are enabled
  3. NSFW content is allowed
  4. Users can create new communities

...otherwise new users (eg from reddit) are not going to use lemmy because it won't match their expectations.

Personally, I was pretty disenchanted by my experience on lemmy when I first joined. I had to create accounts on like 5 different instances before I found one that worked (that's why I created the comparison table of lemmy instances).

Most new users won't have that perseverance. If, for example, they see there's no downvotes on the "recommended" instance, they'll probably give up and leave lemmy.

Comparison of Lemmy Instances in c/[email protected]
[–] [email protected] 1 points 2 years ago

It doesn't say porn, it says adult. The legend describes how it's determined

Adult "Yes" means there's no profanity filters or blocking of NSFW content. "No" means that there are profanity filters or NSFW content is not allowed.

Comparison of Lemmy Instances in c/[email protected]
[–] [email protected] 2 points 2 years ago

Thanks for sharing! How did you find that one? Do you know who runs it? I really, really like that they have an uptime monitor.

Comparison of Lemmy Instances in c/[email protected]
[–] [email protected] 1 points 2 years ago* (last edited 2 years ago)

Awesome, thank you! 🚀

I see these changes, but I don't understand how the i18n stuff works

Where's the file/commit for the actual text stored for instance_comparison and instance_browser?

Comparison of Lemmy Instances in c/[email protected]
[–] [email protected] 2 points 2 years ago

how do you do that? Is there a guide anywhere for how to setup mastodon seeing lemmy or lemmy seeing mastodon?

3
Comparison of Lemmy Instances (github.com)
submitted 2 years ago* (last edited 2 years ago) by [email protected] to c/[email protected]
33 comments fedilink
 

I created a repo on GitHub that has a table comparing all the known lemmy instances

Why?

When I joined lemmy, I had to join a few different instances before I realized that:

  1. Some instances didn't allow you to create new communities
  2. Some instances were setup with an allowlist so that you couldn't subscribe/participate with communities on (most) other instances
  3. Some instances disabled important features like downvotes
  4. Some instances have profanity filters or don't allow NSFW content

I couldn't find an easy way to see how each instance was configured, so I used lemmy-stats-crawler and GitHub actions to discover all the Lemmy Instances, query their API, and dump the information into a data table for quick at-a-glance comparison.

I hope this helps others with a smooth migration to lemmy. Enjoy :)

0
3D-Printable BusKill (USB Dead Man Switch) Prototype (www.buskill.in)
 

This article is about a new 3d-printable prototype version of the BusKill cable.

The BusKill cable is a laptop kill cord. If you're still struggling to understand what is a BusKill cable and why you'd need a laptop kill cord, there's a 2-minute explainer video that makes this clear:

Enjoy and happy printing :)

view more: next ›