31–40 of 151 posts
From the email i received from patreon i reckon the only actual private thing is the exact sum i pay to who.
Some find addresses to be private, but at-least in my case any one can find where i live by looking on the local yellow pages website.
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.
Earlier quoted context omitted.
How do you distinguish someone who was lax with their security from someone who actually takes it seriously and still got hacked?
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.
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?
I'm wondering what their setup is? 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.
I'm wondering what their setup is? 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.
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?
Earlier quoted context omitted.
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 ba…
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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.