"we take security seriously" reminds me "we come in peace" from Iron Sky :)
Gigabytes of user data from hack of Patreon donations site dumped online
131–140 of 151 posts
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#132Earlier quoted context omitted.
I don't think it's actually that bad; for example, Patreon said that they don't store CCs and that they correctly hashed passwords, and as a consumer myself, I did take that into account. Obviously less knowledgeable consumers don't know what "bcrypt" is, but that's true of any product - you can't judge what you don't know how to judge.
so with two patreon style sites both of which say "we take security seriously" , until they have a breach, how would you judge which one would take better care of your data? The information (AFAIK) about their security mechanisms only got released as a result of the breach, so even assuming you knew what the terms were and how to judge good security from bad, you wouldn't have the information until the site got compr…
You can't judge which is better after a single breach either.
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#133On the bright side if they dump the source code we may finally get a public API
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#134Earlier quoted context omitted.
Not true. For example nginx can use the proxy_pass directive to forward real IP address information and log it
The situation here is that people did not read the docs. Do you think they will start to read the docs for the proxy pass? Aside of that, you cannot securely detect this because what it actually does is passing in a header which if not reliably set can be forged.
I wouldn't assume people didn't read the docs so much as they made a mistake deploying (part of) a development setup to production. Security isn't an all or nothing thing, it's about having a good chance of doing the right thing. I think having to explicitly enable the interactive part, something that isn't really standard either, would be sensible e.g. app.run(debug=True, debug_shell=True). At least that would make people even more aware and limit the potential of incidents to those who actually use the feature.
It's not exactly uncommon that people leak errors, remote code execution is another level though. It doesn't hurt to be careful with such a feature.
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#135This scares me. I'm the eng lead of a startup that's a bit smaller than Patreon. And hey, we program in Python too. We're not vulnerable to this particular problem. And I feel pretty confident that both our stage and production environments are well-protected. However, I can't help but wonder if I'm missing something. I'm sure Patreon felt confident a month ago.
If you'd like some free help I don't mind spending some time looking at your overall setup. Feel free to email me ross [at] ruselabs.com.
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#136"we take security seriously" reminds me "we come in peace" from Iron Sky :)
Unless every single employee actually follows this clause, just one bad apple can ruin every security procedure in the world. Layer 8 is awfully vulnerable...
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#137Earlier quoted context omitted.
Makes me wonder what can be done to prevent this from happening without making it a terrible experience from a user point of view. Maybe the solution would be to store a password for the debugger and ask for it on first usage.
It said the guys name in the subdomain that this was available on. I can only imagine how that guy must feel, worst thing that I can imagine happening as a dev. We've all made stupid mistakes and not paid a price as high as this!
Mistakes happens. But it should not be possible to put production data in publicly accessible systems by mistake. Not without committing a criminal offense, at the very least.
Your customer data is your customers' data. It's not yours to toy with as you please.
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#138I've never heard of Patreon until now. This might be the most press they've ever gotten. At what point do we start asking questions like, did this company "hack" themselves for the publicity? There is a great moral hazard in providing so much free publicity to companies that get "hacked."
I have heard of Patreon, and used it to support a number of artists and other projects.
You and your one brain and human experience are an incredibly bad sample size. :)
And why in the world would they want to get PR by faking a data breach?
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#139"we take security seriously" reminds me "we come in peace" from Iron Sky :)
Unless every single employee actually follows this clause, just one bad apple can ruin every security procedure in the world. Layer 8 is awfully vulnerable...
>Unless every single employee actually follows this clause, just one bad apple can ruin every security procedure in the world.
the point of good security architecture is exactly that such thing can't happen. Security by compliance isn't good security.
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#140Earlier quoted context omitted.
The situation here is that people did not read the docs. Do you think they will start to read the docs for the proxy pass? Aside of that, you cannot securely detect this because what it actually does is passing in a header which if not reliably set can be forged.
I wouldn't assume people didn't read the docs so much as they made a mistake deploying (part of) a development setup to production. Security isn't an all or nothing thing, it's about having a good chance of doing the right thing. I think having to explicitly enable the interactive part, something that isn't really standard either, would be sensible e.g. app.run(debug=True, debug_shell=True). At least that would make…
I implemented a pin based system now. It prints a PIN on first usage in 8 hours to the terminal and you need to enter it to unlock the console. This is IP bound.
It's still only a way to prevent greater damage, you should still not run the debugger enabled in prod.