Hacker News new | comments | show | ask | jobs | submit login

i guess it's useful to keep this data from a db admin, but whoever admins the server that encrypts the data must have access to the encryption key(s).

it does further restrict who can access data which is good and it seems to come at a serious cost in complexity. if your db admin is bleeding company data i think your problems are just beginning...




You're not going to escape having to trust someone along the way, the goal is to minimize this trust. Presumably the win with CryptDB is that you don't want to trust Joe Developer who is writing SQL queries, and you don't want to trust Evil Steve who is walking around the cloud datacenter with a bolt-cutter and a USB drive.

Right now, if you want to store sensitive data, you basically have to do it all in-house, which costs big money (think of all the PCI regulations you have to satisfy and auditors that you need to pacify).


I think the idea is that a users data is encrypted with their password, or a key derived from it. So the key doesn't really sit anywhere that the admin can access it, it only exists in memory for a short period of time when the user enters it into the website, and the web app is decrypting the data using it.

This doesn't just defend the data from unscrupulous sysadmins, it also defends data from hackers who manage to gain access and run a mysqldump.


Actually, your first statement is not true. They also present a multi-user mode, where the keys are generated by a user's password when they login. The keys only remain active while the user is logged in, so if somebody gets a hold of your proxy only those users data is vulnerable. Although, I will admit, the paper seems to assume an attacker only gets a small attack window (I believe) and hasn't just installed something that monitors the proxy indefinitely.


The point you raise about attackers monitoring the proxy for a long time is important.

My understanding is that CryptDB offers no protection from attackers who sit between the proxy and the web server. Obviously the web server (or other client) must deal with plaintext, otherwise application software would require changes. The authors of CryptDB assert in no uncertain terms that this is a drop in solution that requires zero application changes, therefore the proxy must do all the work.

The idea is to run the proxy on a different machine than the database, thus allowing the maintenance of the database server's hardware, OS, and RDBMS software to be outsourced without providing access to your data. No amount of monitoring of traffic between the proxy and the RDBMS should matter.

The weakest part of this system is that is appears to store the data in the database with different types of encryption that allow for various operations to be performed on the cipher text. I think that anyone who controls the database system can obtain some of the weaker cipher texts of the data and possibly break them.

I really can't be sure until I test it out... I'm kinda disappointed that it doesn't come with quick instructions to get it going on postgres.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: