I am currently developing a piece of software where files need to be uploaded and then shared with other people that are not on the platform itself.

Here is my approach on encryption:

  1. A user has a master password, of which only the hash is stored (used for login)
  2. When a file is uploaded by the user, a random password will be
    generated and the file will be encrypted with it (all client-side)
  3. The password will be encrypted with the master password, and then
    stored alongside the file

When a file is shared with an outside user, the following steps are taken:

  1. The logged in user shares the file. The file key is retrieved and decrypted with the users password on the client side
  2. The user may now share the password and the file, or use a link to the file with the password in the location hash. The file will always be decrypted on the client side

Is this approach safe? Also, are there any better options?

  • How is the decrypted, file-specific password shared with the outside user? – Steve Sether Jun 6 at 19:50
  • The user has to find a secure way to share it. He can also share a link, then the password is put in the location hash of the link, where the server cannot access it. – NikxDa Jun 6 at 19:53
  • 2
    I'd say that's your primary attack mode. – Steve Sether Jun 6 at 20:48
up vote 6 down vote accepted

Is the approach safe?

No - not if I understand your threat model.

Depends on your threat model. If you never ever want the server (or db or db-backup) operators to be able to decrypt the files, never ever give the server the file encryption key.

In your model the clearest threat is I can brute force guess the password of the registered user. Once I do that, I can decrypt the file encryption key, and the file itself.

update

Thinking about the password a bit more and more threats to this approach:

in general, a user derived password is not safe. One way to think about this is eventually the pw will be compromised. Maybe phishing, keylogger, finding it written under a keyboard, or brute forced. So say I get a copy of the database, now I simply wait for the pw over time (or actively try to hunt for it). Once I have it, I decrypt everything the user’s uploaded that’s in my copy.

We built this differently. (to prevent that threat)

We based our build off send.firefox.com.

When a file is uploaded, it is encrypted client side, and stored on the server. The encryption key is stored on the generated URL and not sent to the server.

The url is sent to the recipient, and the url can only be used once, and expires in 24 hours.

We added to this - after you upload a file, we return a system generated passphrase (two common 5th-grade-level english words).

To download the file, you need the secure link, and to know the passphrase.

The beauty is there isn't any user registration required.

  • Thank you for your answer! You are right, brute-forcing the password would allow operators or intruders to decrypt the files. I can circumvent this problem by enforcing a strong password. The problem with the send.firefox.com approach is that I do not immediately share the link. I can upload a file, then share it a few weeks later. Therefore, the encryption key has to be stored on the server somehow. – NikxDa Jun 6 at 21:26
  • I thought send.firefox.com used WebRTC and didn't store anything server-side. – forest Jun 7 at 3:41
  • Stores the encrypted binary, the IV, and the expiration time. – Jonathan Jun 7 at 3:59
  • @NikxDa updated the answer to explain more reasoning. – Jonathan Jun 7 at 16:30
  • If the key is in the link then it's sent to the server when the link is accessed. – Tanath Jun 13 at 0:25

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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