Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I work for a company that provides a web app where we would like to give the user some sort of "digital safe". In this safe, the user can store and download whichever files he wants.

The idea is that the system generates a symmetric key for an user and this key will be used for encrypting and decrypting the files inside the safe. This key will only be generated once for the user and as soon as he downloads it, it will be deleted from the server. If the user wants to see what is inside the safe or wants to put a new file inside, he will have to provide this key. As all files would be encrypted at rest, this should keep us safe in case someone gets access to these files on the server. Plus, if someone manages to steal a users account and password, they still wouldn't be able to see the files unless they also managed to steal the key.

The objective is to really transfer the responsibility of keeping this key safe to the user. We are aware if he loses this key he will never be able to retrieve what stores in the safe again. The idea is to make us less accountable for what he is storing in the safe and to show that not even we, the creators of the web app, have access to his data.

So, summary: disclosure is important. We want to let the user encrypt files and protect them from ourselves and from potential intruders, even if the user's username and password leaks. Letting the user be responsible for his key should make us less accountable.

Is it a terrible idea to let the user be responsible for his encrypted data?

share|improve this question
    
I think there could be an option, to either keep the original file for recovery, or to agree that the key is not stored for recovery, but he could use e.g. google drive to backup it, if he trust it, in some easy way, and this could be kept secret, if he has this backup or not, because it's a separate company, and requires another password or something. It could be Chinese based business for example, so I dont think they would ever handle it to the western police. –  Andrew Smith Jul 10 '12 at 8:16
    
Terrible how? Are you asking if there are security vulnerabilities caused by the user holding the key instead of you? –  Graham Hill Jul 10 '12 at 8:45
    
@GrahamHill yes. I mean, I understand the user also has to take precautions. But in comparison to the app storing all symmetric keys, making the key not available (because the user has them) even if someone hacks the server is safer, right? –  Bhaskara Jul 10 '12 at 12:19
add comment

1 Answer

Given the alternative scenario, where you store the key, in order to ensure privacy you need to authenticate the user - so effectively the users password becomes a surrogate for the key.

It's quite possible to implement the key generation and encryption / decryption on the browser - which avoids a potential disclosure of the key in transmission / on your server. This also solves the problem of disclosure requests - working out what third parties are actually able to demand disclosure can be a bit of a problem. On the other hand, there is some value in providing a service where managed disclosure is part of the offering (e.g. individual accounts are set up as part of a group - e.g. a corporate entity - and the corporate entity can establish formal criteria under which the information can be disclosed to another member of the group).

i.e. whether its a bad idea depends on the business model.

share|improve this answer
    
ah I hadn't thought about that! Is it ok to generate the key, encrypt and decrypt using javascript? can you elaborate a bit on the business model? thanks for the great answer! –  Bhaskara Jul 10 '12 at 12:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.