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.
Comments
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.