From the moment I began my freelance web design business back in 2014, I was collecting payments via Stripe and happily paying their processing fees for the ability to grow my business from just a desire for more freedom to running a company that employs women and supports them to create their own freedom and financial independence.
It never occurred to me that using Stripe to process payments would become one of the biggest risks to my small business.
My Stripe account was hacked due to Stripe’s lax security, over $70,000 of fraudulent charges were processed by the hacker through a fake connected account, paid out instantly to that person via Stripe’s Instant Payments to the hacker’s pre-paid debit card, and Stripe started pulling the money out of my business bank account to pay back the victims of the theft.
And Stripe says it’s my fault that my account was hacked and that I’m liable to pay back the victims of the fraud.
Listen to the full podcast episode or read on to find out exactly what happened and how to protect your business.
On a quiet Monday morning after the Easter holiday, I was sipping coffee on my couch in Columbus, Ohio like I normally do, snuggling with my dog and going through my normal morning entrepreneurial routine of checking emails and DMs on my business account when I see an email from Stripe with the subject line:
“Subject: [Action required] Closure of your Stripe account”
…
I think that there’s plenty of blame to go around, one of which is that Stripe’s marketing makes payment processing with them seem like an easy, simple thing and it really really is not.
On the other hand, they’re not wrong that if your API key is lost/compromised/found on github/the sticky note is stolen from under your keyboard then ultimately that’s a loss caused by you, and they view it as you being responsible for whatever happens with your stolen credentials.
Credential management is not easy, and the default ‘make this API key, paste it in this box, and then presto you take cards!’ doesn’t really explain what risks you’re going to incur by doing that and how to mitigate them. Hell, engineers where I worked who knew better managed to do silly things with credentials - it’s VERY easy to oops just once and not catch it, and hey presto, your stuff is now out there for everyone.
I spent a decade dealing with customer site compromises and it was firmly a case that about 30% of them were due to poor credential choice or management (shitty passwords, oops-my-api-key-is-on-github), 50% of them were due to unpatched or issues introduced by nulled plugins on Wordpress, and the remaining 20% was a mix of various CI (cough jenkins cough) tools used improperly, and just good old fashioned didn’t-patch-it exploits live in the wild.
As another comment says, Woocommerce apparently DOES support limited API keys but their documentation doesn’t actually acknowledge this because it’s just “easier” to make people put in the keys to the kingdom than deal with having to support people who can’t get it working and walk them through doing it a little bit more securely. I’m not really shocked: that’s pretty normal behavior for a lot of developers who want to ship a cool thing, have it do nifty stuff, but don’t want to have to support doing it securely because security is often annoying, adds complexity, and makes people unhappy. Until, you know, someone steals $70,000 and you get stuck dealing with it.
The problem is that creating a “Restricted API Key” means you have to tick “read” or “write” for dozens of different API “resource types”.
So if WooCommerce doesn’t document which resource types are needed, then “Restricted API Keys” are basically not supported because even security-conscious users cannot know how to produce a key that is fully functional yet satisfies the PoLP.
Right, that was my point: Woocommerce doesn’t want to tell people how to do it (even if the code itself would work with one) because then when it doesn’t work they’ll come to them and have to deal with the support.
And the fact it’s dozens of resource types kinda re-states my commentary that it’s not actually as easy or simple as Stripe makes it in the marketing, and Stripe also doesn’t bother to explain to anyone how to safely use the API with restricted keys either; Stripe could just as easily write the documentation for Woocommerce given it’s probably a fairly sizable portion of their small business self hosted customer base.
It’s not all that shocking because rather a lot of software vendors behave in the same way.
I’m curious if any security engineers have covered this incident.
Stripe does support generating Restricted API Keys. With “Restricted API Keys” you’re able to mint a key that can live on your e-commerce website that has permission to accept payments but does not have permission to modify your merchant account’s payout methods (eg adding a new “Instant Payments” debit card to the merchant account as this attacker did).
Unfortunately, I’ve asked WooCommerce to support Restricted API Keys 1 year ago, but they marked it as “low priority”
…I would appreciate if more people would jump-in on ^ that ticket and scold WooCommerce so that they add support for Restricted API Keys ;)
Looks like Woocommerce is responding 👍. It sounds like they’re saying that they do in fact support them, but that the documentation might not make it clear; does that sound accurate to you?
I consider “support” for this as having it documented. It’s not a boolean “on” / “off”. To “support Restricted API Keys” would mean that they document the minimum set of permissions required (which is a long list of properties, each set to “none” or “read” or “write”).
Indeed, I’m very happy to see they’ve changed it from ‘low-priority’ to ‘high-priority’. Hopefully they’ll update the documentation with the permissions needed for Restricted API Keys soon.
Right, I was trying to be a little skeptical when I read her account (make sure she wasn’t blaming them for some misunderstanding on her end), but I’m about 90% sure that I’ve done a few different times exactly what she did (export keys, put them in Woocommerce, done and assume it’s fine.)
Basically, yes, I’m in full agreement with you that understanding in detail what to do (and, ideally, a strong message that people should be careful about doing it in the safe way) would definitely be good.
Yeah, once they document how to use it, I hope they also publish an PSA telling all users to disable their existing keys and migrate to using Restricted API Keys
