maltfield

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

I figured it out. 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.

3
Why OAuth MUST share access token with 3rd party?!? (self.cybersecurity)
 

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
Why OAuth MUST share access token with 3rd party?!? (self.netsec)
 

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?!? (self.cybersecurity)
 

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
Why OAuth MUST share access token with 3rd party?!? (self.security)
 

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
Why OAuth MUST share access token with 3rd party?!? (self.cybersecurity)
 

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?

Follow up to the proposal for working on GDPR issues and moderation dashboard for Lemmy. in c/[email protected]
[–] maltfield 4 points 1 year ago (1 children)

(I see my reply yesterday didn't federate; trying again from an alt instance)

o hai. Curious that you expected a bunch of people to support you within a couple days. I never saw your proposal (buried in a comment thread in one post on lemmy). I'm only first hearing of this 6 hours after you specifically tagged me. I think you could do more to publish & advocate your proposals if you're serious about them..

Before the incident described in the article you're referencing, I had never spoken to any instance admins. Since I published it, I have spoken to several instance admins (many reached out to me), and they all expressed similar frustrations with the lemmy devs and fatigue in contributing to this project.

No matter how much people will tell you that something is important to them, the true test is seeing how many are willing to pay the asking price.

I think it's important to consider that there's many ways that people contribute to Lemmy. Equally as important as the work that the devs are doing is the work that the instance admins are doing. Collectively the community of instance admins are contributing much more money and time into lemmy than the developers are. That shouldn't be discounted. Both should be appreciated.

There are other ways that people take time out of their lives to support Lemmy, such as finding and filing bug reports, writing documentation, answering questions about the fediverse to new users, raising awareness about lemmy on other centralized platforms, etc. These are also all contributions that benefits the project. Don't discount them.

But when our contributions are met with disrespect, it pushes us away. Based on my conversations with countless Lemmy contributors in the past few days, that's where a lot of people are. They don't want to invest any more time or money into Lemmy because of their previous interactions with the Lemmy devs.

This can be repaired, but the Lemmy devs do need to work on fixing their Image Problem.

PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
[–] maltfield 1 points 1 year ago (1 children)

oh, I got too excited. The instance sidebar says image uploads are available 4 weeks after account creation, though :(

PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
[–] maltfield 2 points 1 year ago

This is false.

In the case of the article, the image was never sent to other servers. In fact, that is the last thing it does.

PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
[–] maltfield 1 points 1 year ago (3 children)

How? I want to block my app from being able to upload images.

PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
[–] maltfield 1 points 1 year ago

They already knew I don’t know rust, which is why they said that I need to learn rust before they assigned it to me.

PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
[–] maltfield 1 points 1 year ago

Link for the curious:

Disclosure: That "poor lad" was me. They also threatened to ban me in ^ that ticket.

PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
[–] maltfield 2 points 1 year ago* (last edited 1 year ago)

Author here. A "KYC Selfie" is a selfie photo where you hold-up a State-issued photo-identity document next to your face. This is not a US-specific thing; it's also used in the EU.

I used to work for a bank in Europe where we used KYC seflies for authentication of customers opening new accounts (or recovering accounts from lost credentials), including European customers. Most KYC Selfies are taken with a passport (where all the information is on one-side), but if your ID has data on both sides then the entity asking you for the KYC seflie may require you to take two photos: showing both sides.

Some countries in the EU have cryptographic authentication with eIDs. The example I linked-to in the article is Estonia, who has made auth-by-State-issued-private-key mandatory for over a decade. Currently MEPs are deciding on an eID standard, which is targeting making eIDs a requirement for all EU Member States by 2016.

I recommend the Please Identify Yourself! talk at 37c3 about the state of eID legislation as of Dec 2023 (and how to learn from India, who did eID horribly wrong):

PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
[–] maltfield 1 points 1 year ago

They definitely should remove it, at least until moderation tools are available.

PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
[–] maltfield 1 points 1 year ago

That’s a great idea :) Maybe you can submit a feature request for this on GitHub?

PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
PSA: You can't delete photos uploaded to Lemmy. So don't (accidentally) upload a nude in c/[email protected]
[–] maltfield 1 points 1 year ago

Better to publish such issues on a public website than let it get buried in matrix. People other than devs & instance admins need to be aware of the risks that they’re taking when using Lemmy.

1
PSA: Upgrade your LUKS PBKDF to Argon2id !! (tails.boum.org)
 

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

6
PSA: Upgrade your LUKS PBKDF to Argon2id !! (tails.boum.org)
 

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

13
PSA: Upgrade your LUKS PBKDF to Argon2id! (tails.boum.org)
 

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

3
PSA: Upgrade your LUKS PBKDF to Argon2id! (tails.boum.org)
 

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

17
PSA: Upgrade your LUKS PBKDF to Argon2id! (tails.boum.org)
 

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

6
PSA: Upgrade your LUKS PBKDF to Argon2id !! (tails.boum.org)
 

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

12
PSA: Upgrade your LUKS PBKDF to Argon2id !! (tails.boum.org)
 

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

view more: next ›