3 ms·

This is perhaps a stupid or uninformed question, but if databases are so vulnerable, why is so much information still stored in cleartext? It seems to me that

This is perhaps a stupid or uninformed question, but if databases are so vulnerable, why is so much information still stored in cleartext? It seems to me that taking the extra step to strongly encrypt data prior to writing to tables would make the intruder's job much harder. I speak not only as a programmer and database guy from way back, but as one of the millions of Anthem subscribers whose personal data was stolen a few months ago in a massive breach. I know that "data breach" might well mean the keys were stolen which decrypted an otherwise secure file, but the terminology suggests that the breach was simple access into the system rather than acquisition of the precious keys themselves. Someone with superior knowledge of these things, kindly explain.

tokenizerrr 11y ago
Where will you store the key?
droopybuns 11y ago
If it's a relational database, the core function of the database is to make it searchable. If you encrypt the fields, you have to decrypt everything to search them. So if search or relationships are important to you, encrypting the whole database would be disruptive. There is a type of encryption called "homomorphic" which could allow you to perform operations on encrypted information. I haven't ever tried to implement it and consider it one of those seductive ideas that probably can't get implemented correctly in practice. But if there was a way to deliver an entire encrypted database and still make it useful, homomorphic encryption is the only way I am aware of that would make it work.
- jessaustin 11y ago
  Perhaps the data you need to search is not the same as the data you might want to encrypt? For instance name, address, ssn (or similar), billing info, etc. could all be encrypted and you could still look for e.g. 50yo women in the Northeast USA who haven't had a checkup in the last three years. Of course many DBs need to search by name, but maybe it can be set up to search by a hash of name? Hashes seem a bit simpler than homomorphic search.
  - droopybuns 11y ago
    >>Perhaps the data you need to search is not the same as the data you might want to encrypt? Bingo. That would be the correct middle ground. This is why some of the database compromises that have happened are not complete disasters. I know there have been a few instances of systems that had their db's dumped, but passwords were safely protected by appropriate salting solutions.
tshadwell 11y ago
There's likely a couple of factors which could include these: * A breach to internal database level would, in the majority of systems mean the attacker already has all the keys to use the database system * A database cannot perform a lot of its functionality (e.g. JOINs) without access to the data & if the encryption keys were usable at the database level to perform such functionality it would make the encryption redundant. A working 'encrypted database' system would likely need to use Hardware Security Modules (HSMs) to prevent key exfiltration, you would distribute these to people who need to use the database, who would need to decrypt it in mostly its entirety to use it. It's possible by reworking entirely how modern databases work (fully homomorphic encryption is probably useful here) you could create a system where the database doesn't have to already be fully decrypted for you to use it, but as far as I know it doesn't exist (startup idea?).

tokenizerrr 11y ago

Where will you store the key?

droopybuns 11y ago

If it's a relational database, the core function of the database is to make it searchable. If you encrypt the fields, you have to decrypt everything to search them. So if search or relationships are important to you, encrypting the whole database would be disruptive. There is a type of encryption called "homomorphic" which could allow you to perform operations on encrypted information. I haven't ever tried to implement it and consider it one of those seductive ideas that probably can't get implemented correctly in practice. But if there was a way to deliver an entire encrypted database and still make it useful, homomorphic encryption is the only way I am aware of that would make it work.

jessaustin 11y ago
Perhaps the data you need to search is not the same as the data you might want to encrypt? For instance name, address, ssn (or similar), billing info, etc. could all be encrypted and you could still look for e.g. 50yo women in the Northeast USA who haven't had a checkup in the last three years. Of course many DBs need to search by name, but maybe it can be set up to search by a hash of name? Hashes seem a bit simpler than homomorphic search.
- droopybuns 11y ago
  >>Perhaps the data you need to search is not the same as the data you might want to encrypt? Bingo. That would be the correct middle ground. This is why some of the database compromises that have happened are not complete disasters. I know there have been a few instances of systems that had their db's dumped, but passwords were safely protected by appropriate salting solutions.

tshadwell 11y ago

There's likely a couple of factors which could include these: * A breach to internal database level would, in the majority of systems mean the attacker already has all the keys to use the database system * A database cannot perform a lot of its functionality (e.g. JOINs) without access to the data & if the encryption keys were usable at the database level to perform such functionality it would make the encryption redundant. A working 'encrypted database' system would likely need to use Hardware Security Modules (HSMs) to prevent key exfiltration, you would distribute these to people who need to use the database, who would need to decrypt it in mostly its entirety to use it. It's possible by reworking entirely how modern databases work (fully homomorphic encryption is probably useful here) you could create a system where the database doesn't have to already be fully decrypted for you to use it, but as far as I know it doesn't exist (startup idea?).