4 ms·

Simplest solution to fix this is to change "Since the database runs in local host". Otherwise, it depends on the extent of the compromise. If the attacker got r

Simplest solution to fix this is to change "Since the database runs in local host". Otherwise, it depends on the extent of the compromise. If the attacker got root access, then all of the data is compromised. Note: you can minimize the effects of this compromise by doing one of a few things: storing the hash of data (e.g. with passwords) so that the original data is still (relatively) safe, or you could also have the data encrypted with another key (e.g. if it is a credit card number) that does not reside on the local machine. If the attacker has not gotten root access, you can use different users to separate what potential data the attacker has access to.

pyre 12y ago
I think that it's probably safer to assume that if the attacker controls a local user account, escalating that to root privs "isn't that difficult." I see such comments all of the time here by people that should know about security. Separating concerns be user account has its uses (e.g. sandboxing an app from accidentally screwing with files it doesn't need access to), but I don't think you necessarily want it as the linchpin of your encryption strategy.
- chacham15 12y ago
  That is not a fair assumption. The reason being that you know nothing about the type of vulnerability that they are exploiting. For example, if the site has a SQL injection attack, user separation in the database would prove quite useful. > but I don't think you necessarily want it as the linchpin of your encryption strategy. Its not about having one thing at "the linchpin". In fact, you should not rely on any singular thing, but rather separate out pieces of information so that no part has more than it needs. The test user should not have access to the production database and vice versa. In sum, you should use multiple things to defend yourself, not just one.
superuser2 12y ago
But if the database doesn't run on local host, the credentials to connect do it still have to.
- chacham15 12y ago
  Those credentials are only to a specific database user though. That user might not have access to credit card tables for instance. Therefore, even if the current exploit provides root access, those numbers might still be safe. Furthermore, it is a much simpler matter to revoke a users credentials than to deal with a machine which has been compromised in potentially numerous ways.

pyre 12y ago

I think that it's probably safer to assume that if the attacker controls a local user account, escalating that to root privs "isn't that difficult." I see such comments all of the time here by people that should know about security. Separating concerns be user account has its uses (e.g. sandboxing an app from accidentally screwing with files it doesn't need access to), but I don't think you necessarily want it as the linchpin of your encryption strategy.

chacham15 12y ago
That is not a fair assumption. The reason being that you know nothing about the type of vulnerability that they are exploiting. For example, if the site has a SQL injection attack, user separation in the database would prove quite useful. > but I don't think you necessarily want it as the linchpin of your encryption strategy. Its not about having one thing at "the linchpin". In fact, you should not rely on any singular thing, but rather separate out pieces of information so that no part has more than it needs. The test user should not have access to the production database and vice versa. In sum, you should use multiple things to defend yourself, not just one.

superuser2 12y ago

But if the database doesn't run on local host, the credentials to connect do it still have to.

chacham15 12y ago
Those credentials are only to a specific database user though. That user might not have access to credit card tables for instance. Therefore, even if the current exploit provides root access, those numbers might still be safe. Furthermore, it is a much simpler matter to revoke a users credentials than to deal with a machine which has been compromised in potentially numerous ways.