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?

  • 1
    I'm confused. How is this supposed to anonymous? And for whom? The people downloading the file? Or the person hosting it?
    – Ajedi32
    Commented May 18, 2015 at 20:28
  • It is anonymous in that we have no idea who the recipients could be. We don't want them to have to create accounts. Commented May 18, 2015 at 20:32
  • You sort of state a solution without describing your problem. I'm not sure what the anonymity you require is. I guess that you have a need for keeping the contents of the zip confidential because you're encrypting the zip but you don't specify what your goal is. What attacks are you trying to prevent by blacklisting IPs? Commented May 18, 2015 at 20:33
  • @Ghost If you don't know who the recipients are, how do you expect to password protect the ZIP file with the recipient's email address?
    – Ajedi32
    Commented May 18, 2015 at 20:35
  • We'll know the email address when we send them a link. Commented May 18, 2015 at 20:36

3 Answers 3


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.


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.

  • How is an encrypted token more secure than a randomly generated identifier? From a security perspective it seems equivalent, but relies on keeping a single secret for a long period of time. Commented May 19, 2015 at 14:57
  • If you have a random id you have to keep information about associated file, expire time etc at the server side to verify, that the id is valid and for the requested file. You have to do this for each id as long as it is valid. If you put instead all these information into an encrypted (and manipulation-resistant) token you need only a single server side secret. Commented May 19, 2015 at 15:18
  • Yes that's true. But from a security perspective keeping one secret for a long time is a compromise. Tracking the random IDs to a file and expiration date is a simple matter in a database. Which approach you use is a matter of judgement and the specific use case, but the point being you haven't increased the security by encrypting the token, you've arguably decreased it since the password is now a single point of security failure. Commented May 19, 2015 at 16:42
  • You can refine the method by having multiple rotating secrets with an overlapping expiration time, but these are implementation details. Commented May 19, 2015 at 20:02

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .