6 ms·

It's called defense in depth. Google the term, it's a useful mechanism for real security.

tptacek 9y ago
If that's true, why encrypt just once? Why not three times, and then add a rot14 just to be safe? Every millimeter of depth counts!
- philipwhiuk 9y ago
  Because encrypting once adds noticeable depth against straightforward attacks. Encrypting multiple times adds practically nothing.
  - tptacek 9y ago
    The problem is that encrypting once in a conventional database design does not add noticeable depth. The server needs to be able to decrypt automatically in order to function. Whatever the server does to decrypt, the attacker will do too. It helps here to understand two things: 1. When we talk about protecting servers with encryption, we're stipulating attackers with RCE. That was the case with the Equifax attacker and is routinely the case in real-world applications. 2. SQLI, the app-layer non-RCE attack that gives you direct access to raw database rows (ie: the one non-RCE case in which you'd get access to the data we're encrypting) almost always equates to RCE anyways. There are real designs that involve cryptography that mitigate these problems. They fall into two buckets: 1. HSM/Crypto "oracle" schemes that are backed by intensive staffing and monitoring. Yes: nobody disagrees that Equifax should have had a serious security team doing serious monitoring. But: if it had that, it wouldn't have had this breach, which involved a published critical framework vulnerability. In other words: in bucket 1, "encryption" isn't helping you, "better security team" is. 2. Moon math schemes. I'm all for moon math, but when people say "phwat!? Equifax worn't even encrypticated?", they do not as a rule have a particular moon math scheme in mind (or, likely, an appreciation for what it means to be the first at-scale deployment of a new moon math scheme). I am not mounting an argument that people shouldn't encrypt things. Hard drives do get lost. I'm just saying that as an operational security mitigation, encryption isn't doing what 99.99% of developers think it's doing in this scenario. (by the way, I can't take credit for the term "moon math" but it is super useful)
    - Blazespinnaker 9y ago
      Lol, if you don't encrypt what keeps some employee from just walking in and stealing the hard drives? Insider attacks are huge, learn this in sec 101. RCE is your area, I am sure, but you are missing a huge category of trivial attacks if you don't encrypt.
- schoen 9y ago
  I don't think this answer is fair. If the encryption is deployed to ensure that only a subset of systems that process or transmit sensitive information can understand it, the attack surface that results in disclosure of the information has been reduced. Elsewhere in this thread you said that a compromise of a database is likely associated with a compromise of systems that access that database, but this is not necessary true if the platforms and administration of these systems are very heterogeneous (say, different operating systems), and in any case it doesn't make it not an application of defense in depth. (Suppose that 90% of attacks that penetrate the database also penetrate the client; now this use of encryption has managed to beneficially mitigate 10% of these attacks.)

If that's true, why encrypt just once? Why not three times, and then add a rot14 just to be safe? Every millimeter of depth counts!

philipwhiuk 9y ago
Because encrypting once adds noticeable depth against straightforward attacks. Encrypting multiple times adds practically nothing.
- tptacek 9y ago
  The problem is that encrypting once in a conventional database design does not add noticeable depth. The server needs to be able to decrypt automatically in order to function. Whatever the server does to decrypt, the attacker will do too. It helps here to understand two things: 1. When we talk about protecting servers with encryption, we're stipulating attackers with RCE. That was the case with the Equifax attacker and is routinely the case in real-world applications. 2. SQLI, the app-layer non-RCE attack that gives you direct access to raw database rows (ie: the one non-RCE case in which you'd get access to the data we're encrypting) almost always equates to RCE anyways. There are real designs that involve cryptography that mitigate these problems. They fall into two buckets: 1. HSM/Crypto "oracle" schemes that are backed by intensive staffing and monitoring. Yes: nobody disagrees that Equifax should have had a serious security team doing serious monitoring. But: if it had that, it wouldn't have had this breach, which involved a published critical framework vulnerability. In other words: in bucket 1, "encryption" isn't helping you, "better security team" is. 2. Moon math schemes. I'm all for moon math, but when people say "phwat!? Equifax worn't even encrypticated?", they do not as a rule have a particular moon math scheme in mind (or, likely, an appreciation for what it means to be the first at-scale deployment of a new moon math scheme). I am not mounting an argument that people shouldn't encrypt things. Hard drives do get lost. I'm just saying that as an operational security mitigation, encryption isn't doing what 99.99% of developers think it's doing in this scenario. (by the way, I can't take credit for the term "moon math" but it is super useful)
  - Blazespinnaker 9y ago
    Lol, if you don't encrypt what keeps some employee from just walking in and stealing the hard drives? Insider attacks are huge, learn this in sec 101. RCE is your area, I am sure, but you are missing a huge category of trivial attacks if you don't encrypt.
schoen 9y ago
I don't think this answer is fair. If the encryption is deployed to ensure that only a subset of systems that process or transmit sensitive information can understand it, the attack surface that results in disclosure of the information has been reduced. Elsewhere in this thread you said that a compromise of a database is likely associated with a compromise of systems that access that database, but this is not necessary true if the platforms and administration of these systems are very heterogeneous (say, different operating systems), and in any case it doesn't make it not an application of defense in depth. (Suppose that 90% of attacks that penetrate the database also penetrate the client; now this use of encryption has managed to beneficially mitigate 10% of these attacks.)