2

We have a software that sends out invoices by email. As the invoices contain the names of the clients and their addresses we consider the invoice to be sensitive to some degree.

Rather than sending out the actual file we provide the clients with a link so they can download the invoice from a website. The filename is made up of a GUID so that is reasonably hard to simply guess a valid/actual url/filename.

The idea behind this approach is that

  • we cannot expect our clients to be able to use encrypted emails therefor regular unencrypted emails have to be used
  • the attached file is way easier to manipulate or replace in an unencrypted email than it is on the webserver
  • obviously the link could also be manipulated however we think this would be easier to notice
  • the GUID-filename provides some degree of security against simply guessing a valid filename (an additional password is considered to be too complicated by some of our clients)
  • we reduce the size of the email and therefore the size of the mailboxes of our clients

Therefor we think it is a safer and better approach to email the link rather than the actual file.

We have some clients that consider this approach to be worse than attaching the file to the email. Besides convenience they reason that the files are now on the public internet and can be accessed by anyone. Which is technically true, however you would have to have the correct GUID to download such a file and we consider the chance of guessing a valid GUID to be rather slim.

Is there anything fundamentally wrong with our reasoning? Would attaching the file directly to the email in fact be safer?

4 Answers 4

1

we cannot expect our clients to be able to use encrypted emails therefor regular unencrypted emails have to be used

Sadly true.

Moreover, the recipient server might not speak STARTTLS, and the connection may fall back to plaintext over the wire. (I expect your mail server to at least try to use STARTTLS always, bonus points for SMTP STS support)

the attached file is way easier to manipulate or replace in an unencrypted email than it is on the webserver

It depends on the type of risks you face. A file on the webserver could easily be manipulated by you, or if your webserver was somehow compromised.

A week after sending it you might change the invoice doubling the amount. If the invoice was in an attachment you would not need to do anything.

we reduce the size of the email and therefore the size of the mailboxes of our clients

I find this is an important point for mails with large attachments and accounts nearly their quota. On the other hand, the attachment is simpler for archiving, as that allows to simply keep the emails (maybe automatically filtered into a folder), whereas the link requires someone to download it (autodownloading scripts are probably magic for most of your clients accountants). And some Cloud email solutions offer infinite mailbox storage, so while for some clients it's important, it will be a non-issue for others.

obviously the link could also be manipulated however we think this would be easier to notice

The average client would probably not notice that the link goes now to a completely different domain.

the GUID-filename provides some degree of security against simply guessing a valid filename

I expect you mean a random GUID (type 4). Yes, an url with enough entropy should be 'good enough' if handled properly. However, the secrecy of the file is as good as the security of the url.

It is probably easier to "leak" the url than the file. For example, an email filtering or antivirus solution might share the url as "bad". The user itself could scan the url in VirusTotal (that will then happily download the "public" file). Some users will nevertheless also share the attachments, though.

It would be much preferable that the files are encrypted. As they are invoices, they could be password-protected pdf, so the clients wouldn't even need to use a different program to open them. Although if there's an expectation that the clients will want to store the invoice without password protection, I would use a password protected zip file (using the modern AES encryption, of course, not the unsafe classic one).

Even if you include the password in the email along the url (which will still make some people claim is not secure, as someone that stole/copied that email would have both the url and the password at their disposal), that would be safer [than not having a password at all], as an inadvertently leak of the url would lead to a file that is still password protected.

Moreover, the storing the invoices encrypted also protect you somewhat against potential mistakes from your part (e.g. your random GUIDs turn out not to be that random, and someone downloads all the files). Particularly, when you use a different random password on each email and don't store it, so even you couldn't reveal its contents (OTOH if in the same system you were storing a db column with "the" pdf password for each customer, an attacker might steal everything).

In general, in my opinion adding a password to the file seems a measure adding interesting benefits while requiring low skills from the receiver. But, this is a feature you are rejecting:

(an additional password is considered to be too complicated by some of our clients)

and this reveals your actual problem. You are trying a one size fits all approach, but some of your clients consider attachments preferable than links (while others will consider the opposite), some demand a "more secure" approach and others are unable to open a password-protected file.

I think you should make it configurable.

Use a reasonable default, with password protected files (either as an attachment or as links, allowing them to change that), but let the user "dumb it down" by actually disabling the file encryption, and also provide a PGP key to which you would encrypt their email (and/or linked file).

That later option, while being the most secure one, will be a niche one with only a tiny fraction of your clients actually using it, even with a fairly technical user base. So the actual value of that option is probably going to be the availability of it more than the users of it: that you can offer your clients to use a much more secure way for sending them the invoice, if so they wish, even though they are most likely to decline.

1

The email can be forwarded to anyone. Thus anyone can get access to it.

Better would be to add authentication and set access for specific users only. Then no matter to whom the email will be forwarded, you will have full control on who can access the link. Such approach is not new. It is widely used, in particular in MS Office 365 and in Google Docs.

0

I can see good points on both ways.

If the link is not password protected, the client have a point. It's practically impossible to guess the GUID, but bookmarks can leak, user can paste the link on the wrong window, or send to the wrong person. It could happen to the attached file too, but it's harder to mis-attach a file than to paste a link. You could solve that by registering an account for every client and asking for the password before giving the file.

On the other hand, having the link allows you to edit the contents of the file after the email has been sent. If something was wrong on the original file, you don't need to send another email with the new version, you just edit the file server-side and tell the client to re-download the file if needed.

Having the link means your service is really are the one with the data file, but attaching a file on the email don't prove that with the same certainty. DKIM, SPF and DMARC are useful to prevent email spoofing, but misconfigurations happen all the time. It's easier to spoof email from a misconfigured server than to break into a webserver, change a file and send an email with a poisoned link to its customers.

0

The obvious downside in sending a URL link in the email is that you train your clients to follow links. This is bad from a social engineering point of view e.g. an attacker sends an email to one of your clients (that looks like it came from you) which provides a link to malware - most clients that are not security aware will follow the link and will be infected. However, if your clients are not security aware then, in my opinion, you are the least of their problems.

Aside from that, the way you will deliver the invoices should be the result of legal constraints and technical preference; legal constraints is about what laws do you have to comply with. Technical preference is which way is easier for you to maintain.

If you are in a jurisdiction where there's a legal requirement to protect the data, then sending invoices in the clear is not the way to go - and you have the arguments to support that. Of course, this depends on the data that the invoices include - not all data require protection by law.

On the other hand, your customers that feel uncomfortable with just the link may not realize that unprotected emails are exposed to the public too - but they do have a point in that sniffing an email and accessing a public link introduce completely different attack surfaces (with the public link being worse). As such, you should probably address their concerns by adding more protection measures (in your case, UUIDs being hard to guess is a single point of failure).

A simple solution would be that the URL link should be TLS protected (i.e. use the https scheme), and require clients to provide a username (client id) and password in order to access the invoice. Again, for the clients that don't want any of this, the legal constraints may work in your favour.

You must log in to answer this question.

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