Sending sensitive data via email is a terrible idea

Sending sensitive data via email is a terrible idea

One of the most common ways to exchange information nowadays is email. We send and receive emails everyday, at home and at work. The average US worker –apparently– sends and receives 100+ emails per day. While most emails contain non-sensitive information for which email is perfectly suited, almost everyone does send or receive sensitive documents via email every now and then.

Email is insecure.

The first email system was developed in 1971 and although a lot has changed, at its core it hasn’t changed that much. Email providers do their best to secure email communication but its security is always as strong as the weakest link.

Email encryption

Over the years, encryption has been added to email at different levels. Especially communication between clients (e.g. you) and email servers has been improved by adding encryption (SSL, TLS). Most of the time, this is optional –not enforced– meaning it’s your responsibility to enable it.

Also communication between email servers –emails in transit from one server to the other– can be encrypted. Nowadays this is quite common, however definitely not supported by all email providers out there. Most email server software allows enforcing encryption for server-to-server communication, meaning Server A will not deliver emails to Server B if Server B doesn’t support encryption. Although enforcing encryption for server-to-server communication improves security a lot, most email providers do not do so because it would block a lot of emails.

Another measure an email provider could take is to encrypt emails before storing them on a server’s hard drive. Most major email providers like Gmail do so, but most company-owned servers don’t. If Hillary Clinton would have encrypted her emails, the hack of her server wouldn’t be such an issue.

PGP

In 1991, PGP (Pretty Good Privacy) was born. PGP uses asymmetrical encryption to encrypt emails.

Asymmetrical encryption works with a pair of keys –a public key and a private key– which belong together. Information encrypted with the public key can only be decrypted with the private key and the other way around. Normally you distribute your public key and keep the private key… well, private.

With PGP, you exchange public keys with the one you want to communicate with. Then you both encrypt outgoing emails with the other one’s public key. This ensures only the one with the correct private key –the intended recipient– can decrypt the message.

Although using PGP is way better than just sending plain text emails, it has its downsides. Like email, PGP is –at its core– dated technology: 28 years and counting. Improvements were made, but can’t be enforced because it has to support software that hasn’t been updated.

Furthermore PGP is cumbersome. You have to exchange public keys before you can communicate securely, and setting up PGP including generating keys is something that’s way too difficult for the average email user. Even Edward Snowden had issues with PGP. Web based PGP email providers like ProtonMail and StartMail make PGP easier for senders, but communication with recipients not using PGP will have to revert to something else, less secure.

How should you exchange sensitive data?

So we’ve established sending sensitive data via email is a bad idea. However you still need to send that passport or bank statement to your financial advisor. Email can’t be trusted so we need to add a security layer on top of it. If information is encrypted before it leaves your device, and decrypted after it arrives on the device of the recipient, we call it end-to-end encryption.

When data is end-to-end encrypted, only the sender and the receiver have access to the (unencrypted) data. Although using Google Drive, Dropbox or a similar service is more secure than email, these do not use end-to-end encryption. This means that these services could have access to your data, e.g. when requested by governments.

How to transfer data with end-to-end encryption? There are several options.

Zip it (or other manual ways of encryption)

First of all, you can zip the files you need to send and protect the zip with a password. Now you can send the zip file via email, and share the password using another medium, for example the phone or an instant messaging app. However, most zip software don’t use very strong encryption algorithms meaning the zip files can quite easily be cracked. Furthermore you need to use long passwords to enhance security, and there are quite some manual steps involved. So let’s continue looking.

Messenger apps

You can also use an instant messaging app with end-to-end encryption, like Signal or Telegram (or even WhatsApp nowadays). This is perfectly secure because these apps use strong end-to-end encryption and are battle-tested. For consumer-to-consumer file exchange, this may be a nice method. But both the sender and the receiver need to have an account. Furthermore, this isn’t the most professional looking method for companies.

Firefox Send and similar tools

In 2019, Mozilla launched Firefox Send. Send is a web based file sharing tool. The sender of the files uploads the files to Send and shares a personal link with the recipient. Files are encrypted before they are uploaded and are decrypted after they are downloaded, so they are end-to-end encrypted. The decryption key is contained in the shared URL, meaning everyone in possession of the URL can open the files. Mozilla solved this by allowing to enter a password, which the sender can share via (preferably) another medium.

SafeRequest

Some months ago, my company launched SafeRequest. SafeRequest is a (free) service which has some similarities with Firefox Send, but has one (actually more 😉) important difference: the process is reversed. Instead of putting the security responsibility in the sender’s hands, it’s in the hands of the requestor of the information. For businesses, this means they can provide their customers a very nice and easy way to deliver documents, without them having to sign up for a service or install some kind of software.

SafeRequest allows the requestor to specify exactly which files they want to receive, after which a unique URL can be shared with the one who needs to deliver the files — for example via email. Files can be uploaded via a branded upload page and are end-to-end encrypted. But wait… it’s even more secure!

Just like Firefox Send, SafeRequest encrypts files with a randomly generated key. This key is generated at the moment the uploader starts to upload files. Then, SafeRequest uses a process similar to PGP: it encrypts the randomly generated key, now using asymmetrical encryption. The key is encrypted using the public key of the requestor –which was generated during their account registration–, meaning only the requestor can decrypt the encrypted key, so only the requestor can decrypt the files. SafeRequest does not have –and does not want– access to the requestor’s private key, so also we cannot access any file.

Another security advantage: as the requestor initiates a specific file request, files are never accidentally sent to the wrong person. Sending files to the wrong persons is one of the most common reasons for leaked emails (in 2019, 63% of the Dutch data leaks were caused by using wrong email addresses).

SafeRequest helps companies to comply with privacy regulations like the European GDPR and the Dutch –that’s what we are– AVG.

Secure your data!

Of course we would love you to try SafeRequest, but in the end the most important thing is that you stop sending sensitive documents via email and start using some other way to exchange your data.

I’d love to hear your feedback about this article in general and about SafeRequest specifically, so feel free to comment :-)