Database encryption doesn't make a whole lot of sense to me. Proper row and column security, and using real database user authentication (not one single, pooled web server user) is real security. A db on its own box, in its own network zone, physically controller by the data owner.
What's the threat here?
SQL Injection? Encryption won't help. Use parameterized queries and least privilege.
Evil admin? They can just monitor the web server instead of the db.
Appications should be architected so that security-critical logic happens on the client. See how Mega and SpiderOak do that. This way, the attacker has to hack every computer of every client instead of one single server.
Of course, this requires making sure that the code which the client executes is not malicious
I can see this being useful for the example you gave, Mega. Currently, the list of files you upload are all downloaded to the client in order to do a search. If the search could happen on the server but the file list remains encrypted, that would make the website less costly for the client.
yeah there are no perfect trade offs:
if you control the application server then you just instruct clients to decrypt/give away their data/encryption key
still its more effort and more opportunistic (client needs to actually connect that day) so it is safer/reduces likelihood.
But a lot of work and issues for the security gain compared to db encryption and proper design (even thus, you know, its not a great trade off either!)
In the end I guess we need a truly client-initiated and controlled data handling. HTTP isnt exactly made for that. It tells the client how to handle and control the data, no choice is really made client-side.
I think the idea is that the data is never decrypted until it returns to the client. i.e. it's encrypted client side while being indexable server side.
This means that your 'evil admin' case is invalidated since the plaintext data is never available to the host.
I think this project could be used to secure against evil admins. Especially if you make CouchDB-style apps (communicate directly with the DB from the browser or desktop/mobile app)
Comments
Database encryption doesn't make a whole lot of sense to me. Proper row and column security, and using real database user authentication (not one single, pooled web server user) is real security. A db on its own box, in its own network zone, physically controller by the data owner.
What's the threat here?
SQL Injection? Encryption won't help. Use parameterized queries and least privilege.
Evil admin? They can just monitor the web server instead of the db.
Appications should be architected so that security-critical logic happens on the client. See how Mega and SpiderOak do that. This way, the attacker has to hack every computer of every client instead of one single server.
Of course, this requires making sure that the code which the client executes is not malicious
I can see this being useful for the example you gave, Mega. Currently, the list of files you upload are all downloaded to the client in order to do a search. If the search could happen on the server but the file list remains encrypted, that would make the website less costly for the client.
yeah there are no perfect trade offs: if you control the application server then you just instruct clients to decrypt/give away their data/encryption key
still its more effort and more opportunistic (client needs to actually connect that day) so it is safer/reduces likelihood.
But a lot of work and issues for the security gain compared to db encryption and proper design (even thus, you know, its not a great trade off either!)
In the end I guess we need a truly client-initiated and controlled data handling. HTTP isnt exactly made for that. It tells the client how to handle and control the data, no choice is really made client-side.
I think the idea is that the data is never decrypted until it returns to the client. i.e. it's encrypted client side while being indexable server side.
This means that your 'evil admin' case is invalidated since the plaintext data is never available to the host.
Is there more to the indexing than MAC-ing the values ?
I think this project could be used to secure against evil admins. Especially if you make CouchDB-style apps (communicate directly with the DB from the browser or desktop/mobile app)
That's exactly the use case. The idea is that the data isn't decrypted until the client.
So the database itself doesn't have much to do with encryption, except that it can help w indexing.