Best case, this is a well meaning project by someone that doesn't understand the implications of sharing secrets. Unfortunately it could be a ruse to harvest api secrets from people that don't understand the implications of secret sharing.
EDIT:
In the case of Stripe keys, I wonder if it's a strategy to bypass Stripe's "carding" detection? It seems like spreading out test transactions across multiple stripe accounts would make detection more difficult.
I disagree with argument that any integration platform that requests your Stripe keys is a "ruse to harvest api secrets." At Pipedream, our Stripe integration requires the user to authenticate using their keys as well - https://pipedream.com/apps/stripe
Stripe Connect & OAuth was something we thought about. It's definitely recognised as a more secure method and it's also low friction to integrate.
The only drawback comes into play with marketplace and platform apps. The platform itself may already be using OAuth with their customer.
We could offer our customers both options and let them choose which one is best.
Oh, wow I didn't realize that. I'm a little surprised it's a common thing. Stripe's secret key is the "keys to kingdom" so to speak. This means someone with the key can get up to all kinds of funny stuff.
Stripe also says not to do it:
> Your API keys give you access to Stripe’s systems and a global financial network. That access is what card testers want to exploit, so it’s important to keep your keys safe and put safeguards around the functionality those keys provide to prevent fraud and other malicious activity.
> Your secret API key can be used to make any API call on behalf of your account, such as creating charges or performing refunds. Treat your secret API key as you would any other password. Grant access only to those who need it. Ensure it is kept out of any version control system you may be using.
To me this sounds like an example of bad practice commonly implemented. Along the lines of the litany of open source projects who's install instructions involve CURLing a shell file into sh directly. It's bad practice, but so commonly implemented people mistake it for good/fine practice.
To be fair, sometimes you need bad practice to make things possible to do. Plaid takes your bank username and password to scrape pages because it’s the only choice to make the tech.
Flouting the rules is the basis for a lot of successful businesses.
A qualified absolutely. I love to build side projects, and generally the first iteration is very poorly built. If your goal is to put "ideas on paper" so to speak, then you're 100% right. This could even make it to early production if you're really in a pinch.
I think though that there's a point where you need to move past the bad practice and find, or create the right way to do what you're trying to do.
It looks like this documentation might predate Stripe's auto-generated API keys, which generates a separate API key for each successive app, and then you are able to identify the app and revoke only those keys:
Giving frontend clients the keys to the castle to send text messages and make calls on your app's behalf seems like a bad time waiting to happen. How are you thinking about the security aspect? I see the word "Security focused", but that doesn't really tell me anything.
Kinda the same deal on Stripe - if someone can guess / find out customer identifiers, which is a lot more likely when you're shipping them to frontends to use with your library (XSS...), they can create charges on your behalf? That's definitely a big risk fanout
- Clients are initialised with Key & ID - We advocate for keys to not be hardcoded
- The key is used for request encryption and are never sent to the server. Request hashes are also used to make sure Man In the Middle Attacks are avoided
- Custom Auth Tokens can be sent with requests - On the server side we use your provided auth callback to ensure it is valid
What do you think about the steps we take? Tokens are really important because they offer another layer of protection
> Clients are initialised with Key & ID - We advocate for keys to not be hardcoded
They're public facing (used by clients), so it doesn't really matter if they're hardcoded or not. I can rip them out of the dom/api calls/whatever.
For the second part, https covers you alone.
Auth tokens may start to pick at the puzzle, but at that point it's not obvious what I'm gaining if I have to bake custom authorization and authentication somewhere in any case?
You have a tough battle here - the security risk is huge. I don't personally see a value add yet, especially with Twilio/Stripe who have some of the lowest cost integration in the industry.
Not impossible to succeed in the arena, but the level of abstraction doesn't feel like the right fit yet
I created a similar project about a year ago that never got much traction: https://paysly.io/
Its similar in principal, but it also creates a signed version of the stripe response [1], so you can hand it off to a backend and validate it without an additional stripe call.
Instead of requiring users to input auth keys, it uses stripe connect [2] to securely authenticate and act on behalf of users.
If you have an app with a traditional backend, you likely wouldn't.
I saw the need when I had a couple of simple apps where I didn't really have a web server where I could create payments/subscriptions via stripe's server-side libraries. I also didn't want to use stripe's Checkout. I had to spin up a simple service just to confirm the payments and I figured I could abstract it.
The signed jwt response can be helpful because now you just need paysly on the frontend and your backend can be dependency free - all it needs to do is parse the token.
I looked around at the website, read the docs, and figured I had to be missing something.
After reading the comments here, I realized that I was not. DO NOT USE THIS! This is a terrible product, and the entire concept should not exist. You're giving the keys to your Stripe and Twilio accounts away to some random third-party for... what, exactly? A slightly simpler development experience?
And there are even more red flags.
- no information about what company/which individual is responsible for the service (I always want to know who I'm doing business with)
- no contact information (no, Twitter is not a business channel)
- no information about anything even related to liability and/or applicable laws
- no ToS
- no privacy policy (so no customers from the EU + possible lawsuits in the EU for the person who runs it)
- no cookie policy, but still a cookie. Even better, it's valid for 10 years... (and here we go again with possible lawsuits in the EU)
Maybe there is some information about this after the registration, but it is:
a) too late
b) not how a serious company should communicate with potential customers/partners.
Not if you handle the card numbers outside of Stripe (through a backend) instead of letting them pass through Stripe's iframe.
It's unclear to me if that's happening here. Stripe CAN work that way, but then PCI compliance is entirely on you (and you might as well get a regular merchant account at that point, since you've already gone to all that effort.)
Anything that touches cardholder data has to be PCI compliant. Stripe offloads PCI compliance for you because Stripe's front-end library lets the card number (etc) pass from your browser directly to Stripe's PCI-compliant backend, without ever passing through your application servers.
If you interrupt or proxy that flow, you become responsible for PCI compliance.
(Note that I have no idea if that's what they're doing here, but they could and you wouldn't even know until your account was closed for fraud. Also, this sort of centralized architecture can easily become a target for attack.)
Yeah, in essence it helps start ups integrate stripe without building their own backend
Startups would put in their restricted key - a secret key with only the access that is necessary.
In terms of pricing, a request is an api call. I can see your point with $5 to send 250 text messages. It does sound steep. The first 5000 requests are at $20 which should adequate for most startups. Majority of our customers don't use more than 750 right now.
If we find customers maxing out the limits too quickly we will definitely adjust our pricing
Also, what does this cost? Is this a business or an open source library?
How does this compare to things like Chargebee or Recurly?
And, most importantly, why are you storing Stripe secret keys? If you are simply doing a better front-end/Stripe Checkout sort of front-end, why not just use the Stripe public key or even a regular Stripe Connect / API key if you need to do private API calls?
A couple of dashboard screenshots:
Stripe key collection:
https://i.imgur.com/q6evqlT.png
Plan Upgrade:
https://i.imgur.com/nwBZ2wL.png
EDIT: In the case of Stripe keys, I wonder if it's a strategy to bypass Stripe's "carding" detection? It seems like spreading out test transactions across multiple stripe accounts would make detection more difficult.
https://stripe.com/docs/card-testing