Is there a better way to have secure downloads without the requirement of an account?

Question

The Job

You have the task of providing large files with sensitive data to people outside your company.

Limitations and mandates

1. Recipients of the data must be notified by email
2. The size of the files prohibit sending the data via email
3. There could be tens or hundreds of thousands of users, so making accounts for them is not an option.
4. A recipient could be anyone who has an email address.
5. You need the capability for a recipient to be able to programatically consume the link and download the file so they could import into their software without human interaction.
6. You need to keep this as secure as possible.

Proposed Solution

I would provide the recipients with a link via an email (TLS secured) and they would simply click the link to download the file. The link would contain a 25 character code that would let them access their file. If an IP (or MAC address?) provided a bad code 10 times, it would be blacklisted for 14 days to prevent a brute-force attack to get access to more files. The file would be a zip that is password protected with the recipient's email address as the password. The files themselves would only be available for a fixed length of time; the expiration of that time would cause the files to get deleted by a back-end process and the code to become available for another download (although it may never be re-used).

So, with my solution, a possible scenario would be: I am given an email address and I need to provide them a file customized for them. I create a file, zip it with the recipient's email address as the password, save it to my application, my application says the URL for the file will be www.test.com/GetFile.aspx?UID=12....99, and then I email them a link.

Obviously, if the email we send them with the link is compromised, the files linked in the email could be compromised as well.

Is there a better approach?

Answer 1

Security needs to be balanced with usability. Encrypting the file with the email address ads only a tiny amount of additional security, and adds complexity for end users.

Locking out the user for 2 weeks after a mere 10 bad attempts is also overkill. I could easily see someone in a company trying 10 times and being unsuccessful and causing you and them enormous headaches. A 25 character randomly generated code is already protection enough, so why worry about brute force attacks that will just cause you trouble?

Expiring the link after a certain period of time is fine, and relatively standard. That means compromising the email box doesn't compromise the file.

Answer 2

Assuming that you have the email for the user and some server side secret you can do the following:

• Create a token which contains the file for download and is encrypted with the server side secret, i.e only the server itself can decode the token. Look at JWT tokens for an example. To make sure that the same file does not result in the same token you might add some random data too before encryption (in case the encryption itself does not provide already some kind of random initialization vector). It might also useful to add an expiration time for the token. And in case the token is not long enough and you fear brute force attacks just add some more random padding to the token (before encryption).
• Send a link with the token to the user by email.
• If the user access the site check the validity of the token (i.e. can be decrypted, HMAC fits, not expired) and extract the file the user wants to get.
• Provide the file to the user. For protection against MITM you could use here https, but note that a potential attacker might have intercepted the mail.

For additional protection against an attacker who might have intercepted the mail with the token you could request some secret from the user at the place where the user requests the file download or you might generate a secret yourself and show it to the user. The secret should be added to the token and need to be provided by the user when downloading the file.

Answer 3

Ideally you'd encrypt the file you want to share with a symmetric key, sign the encrypted file with your private key, then publish the encrypted file in a public place (a publicly accessible web server would work). Then when you want to send someone the file, you'd encrypt the encrypted file's symmetric key with the public key of the user you want to send the file to and email that key to the user along with a link to the file.

The user could then download the encrypted file, verify the file using your public key, use their private key to decrypt the symmetric key you sent them, then use that key to decrypt the file.

This approach is far more secure than the one you suggested in your question, as it doesn't rely on the user's email account being secure in order to keep the file private, and it assures the user that the file they downloaded really came from you.