There is a lot we can do as programmers to make data leaks of that scope a lot harder to pull off. I think web apps of a certain magnitude should not be talking directly to the database, they should be talking to their internal data API that resides on a different server. The reason for this is that a completely separate data layer is easier to lock down, and also way easier to monitor for unusual activity. Ideally,…
Gigabytes of user data from hack of Patreon donations site dumped online
41–50 of 151 posts
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#42There is a lot we can do as programmers to make data leaks of that scope a lot harder to pull off. I think web apps of a certain magnitude should not be talking directly to the database, they should be talking to their internal data API that resides on a different server. The reason for this is that a completely separate data layer is easier to lock down, and also way easier to monitor for unusual activity. Ideally,…
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#43The centralisation of services like this has to stop. Why should giving money to creators be a centralised thing (many to many) instead of just a one to many relationship between the creator and their fans?
So content creators should use PayPal then for donations? That's also a centralized service. How do you propose a transaction takes place without a service to process the details?
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#44Re: Gigabytes of user data from hack of Patreon donations site dumped online
#45Earlier quoted context omitted.
I guess we could argue that if you get security seriously enough you don't get hacked. EDIT: I was being sarcastic. This is a good read: https://www.schneier.com/essays/archives/2000/04/the_process...
No actually we don't. Security, if taken seriously is a set of policies related to software and hardware (in the post-Snowden era). Applying patches like grsecurity, running services through chroot jails, installing IDS systems and reporting tools makes a system (every system) extremely inflexible. Updates become nightmare. Tuning a system to avoid false positives might take a forever and then the topology/setup/clie…
Let's assume they are connecting using an iOS device or OSX on a Mac to run commands on the server. As everyone knows, Apple devices allow full root access from the cloud for Apple to install new applications etc. These same backdoors can often be exploited [1] or leveraged by governments. If we assume an attacker has full control of the laptop the devops engineer is using to secure the system it becomes trivial for him to insert a backdoor in the servers too.
[1] https://truesecdev.wordpress.com/2015/04/09/hidden-backdoor-...
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#46That's pretty devastating to anybody who gave up their data to support things they enjoy. I would really like to see services getting hit with massive fines so they actually "take security very seriously" before they get owned. It's far too late to care about it now, there's a lot of compromising data in that leak.
How do you distinguish someone who was lax with their security from someone who actually takes it seriously and still got hacked?
There is a huge Market for Lemons (https://en.wikipedia.org/wiki/The_Market_for_Lemons) style scenario in IT systems with relation to security.
Everyone will say "we take security seriously", but there's no way for ordinary consumers (or indeed most companies) to determine what the company meant by their statement, and to evaluate the relative security of the systems of two companies.
This could actually provides a market incentive for companies not to spend too much on security, as those that do will have lower profits than those that don't.. until they get breached, and even then companies with good security can be breached...
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#47I had just been listening to the "Talk Python to Me" podcast episode with Albert Sheu of Patreon ( http://talkpython.fm/episodes/show/14/moving-from-php-to-pyt... ). Having heard the guy's voice and his enthusiasm for his work makes me really feel sorry for the team at Patreon. This is pretty much worst case and may end the company.
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#48Earlier quoted context omitted.
I guess we could argue that if you get security seriously enough you don't get hacked. EDIT: I was being sarcastic. This is a good read: https://www.schneier.com/essays/archives/2000/04/the_process...
No actually we don't. Security, if taken seriously is a set of policies related to software and hardware (in the post-Snowden era). Applying patches like grsecurity, running services through chroot jails, installing IDS systems and reporting tools makes a system (every system) extremely inflexible. Updates become nightmare. Tuning a system to avoid false positives might take a forever and then the topology/setup/clie…
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#49I had just been listening to the "Talk Python to Me" podcast episode with Albert Sheu of Patreon ( http://talkpython.fm/episodes/show/14/moving-from-php-to-pyt... ). Having heard the guy's voice and his enthusiasm for his work makes me really feel sorry for the team at Patreon. This is pretty much worst case and may end the company.
Re: Gigabytes of user data from hack of Patreon donations site dumped online
#50There is a lot we can do as programmers to make data leaks of that scope a lot harder to pull off. I think web apps of a certain magnitude should not be talking directly to the database, they should be talking to their internal data API that resides on a different server. The reason for this is that a completely separate data layer is easier to lock down, and also way easier to monitor for unusual activity. Ideally,…
Yeah. I feel like an ideal architecture would be to use NSQ and transmit not queries, but a minified JSON bundle of query "name" with query parameters. Then have stateless DB service nodes preloaded with canned, named queries on secured VMs whose only access to the outside world is NSQ. Bonus, you can tap off DB requests with an ephemeral channel and log them.
I've ran systems like that, and I'm glad things are a lot easier to maintain now (stored procs are a pain in the ass, whether they exist in the database or in the app layer).
Query injection is solved by parameterising queries (never sanitising them yourself), it should not be an issue nowadays, "advanced SQL injection" is a lie, either you can inject or you can't.
If you can inject, it doesn't matter how many protections you put in place, you can always extract data via timing attacks or boolean conditions.