4 ms·

I'm not a security guru, but the most common scenario (even today, that big data and NoSQL/Graph dbs thrive) is a website running on a SQL (with some additional

by atmosx 12y ago

I'm not a security guru, but the most common scenario (even today, that big data and NoSQL/Graph dbs thrive) is a website running on a SQL (with some additional memcached/Redis or Mongo?). Say I encrypt the entries... Since the database runs in local host, if the host is compromised and subsequently 'rooted', what exactly does database encryption offer? The intruder will sniff/find the encryption key(s) since the key must be somewhere inside the application or in memory (don't know how, but I'm sure it's possible) in order to be able to decrypt data on the fly. The way I see it it's just added complexity for the admin with no gain. Is there any way of defending an SQL database even when the host is compromised?

chacham15 12y ago
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.
tptacek 12y ago
Not much. This is a genuinely hard problem. You want to keep data at rest encrypted, but data is restless, and it's hard to predict when each piece of it will wake up. So you end up keeping the decryption keys resident, accessible in some way to the running server. And, as you're intuiting, most things that compromise the server in some way pivot quickly to compromising the whole server, and thus the key. The best answer I have to this problem is a variant of the HSM: the server stores ciphertext but not the key. To decrypt data, it's presented to another server, whose only purpose is to "seal" and "unseal" the data. That server: * Doesn't run on shared hardware * Has a totally different management process from the rest of the app servers * Speaks only to authenticated, trusted hosts * Is carefully monitored for usage anomalies This isn't a panacea; in fact, its security value is surprisingly limited. But it does solve some actual problems.

by atmosx 12y ago

chacham15 12y ago

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.

tptacek 12y ago

Not much. This is a genuinely hard problem. You want to keep data at rest encrypted, but data is restless, and it's hard to predict when each piece of it will wake up. So you end up keeping the decryption keys resident, accessible in some way to the running server. And, as you're intuiting, most things that compromise the server in some way pivot quickly to compromising the whole server, and thus the key. The best answer I have to this problem is a variant of the HSM: the server stores ciphertext but not the key. To decrypt data, it's presented to another server, whose only purpose is to "seal" and "unseal" the data. That server: * Doesn't run on shared hardware * Has a totally different management process from the rest of the app servers * Speaks only to authenticated, trusted hosts * Is carefully monitored for usage anomalies This isn't a panacea; in fact, its security value is surprisingly limited. But it does solve some actual problems.