Sure I'll send that over Slack

13th Nov 2018

Making Things Send Once Encryption Security

This project is inactive and the website no longer exists.

Most of us who work in the tech industry, especially us engineers, are fairly savvy when it comes to security on the internet. Many of us need to consider it regularly as part of our day job. That said, if you ask almost any engineer or tech savvy person they will almost certainly tell you of the terribly insecure ways they have sent sensitive information in the past.

Most non tech people will be aware in some way or another that nothing that they text message or email is really private. However, how many of us have even had a second thought about sending bank account details or even passwords via email or other electronic means in the past?

What is the root of the problem?

The root of the problem here is trust. As is with most of the problems on the internet, the major issue is trust. In this case, it isn't so much if you can trust that a person is who they say they are. The issue is more that, with any message sending provider; you are relying that they won't themselves access your private messages or that they wont allow anyone else to access them.

If you can't be certain that someone else can't access something you are sending, then it's probably a good rule of thumb to not send anything you don't want something else accessing. On a side note, this is also related to the internet in general, if you don't want any information out there in the wild on the internet, don't put it there in the first place.

With the exception of a few specific messaging services who claim to be end to end (E2E) encrypted. The operators of most messaging services essentially have direct access to the messages that you send. For anyone not farmiliar with E2E encryption; it is the process of encrypting a message in such a way that only the sender and receiver can decrypt and read them. In this way, even the operators of the app can't actually read the message as it passes through their servers or is stored in their databases. Even with E2E encryption, there is still a trust issue, you have to believe that the service provider is actually doing it and that they don't have some back door into the secret messages.

But I just have this password I need to send to my colleague

So, as well versed as we all are with security and never sending passwords or secret information over electronic means. We do it anyway. I certainly have and I think most other people have too. Sometimes it's easy enough to think that it wont make any difference, the password isn't that important, no one is ever going to be looking for it in a malicious way, it's fine! This may well be true, however, is it worth the risk? Bad habits are easy to form, it only takes one important password to be leaked to cause major trouble.

The temptation to do this is also slightly exacerbated by services like Slack. Slack is becoming ubiquitous within the tech world, so we have rather a lot of trust in it. However, the same rules apply with it as do all other messaging services.

Okay, okay... But, let's be a little bit clever about how we do it

We have established that we can't trust that the body of our message wont be read by someone else at some point in the future. However, it is unlikely that anyone is going to be snooping on our messages in real time as we sending them. So the content of your messages is probably relatively safe for 5 - 10 minutes.

So if we could send our secret information in some way such that it expired after a short amount of time and become inaccessible, this would greatly increase the certainty that no one can access the information once it's been sent.

If you do a quick search on the internet you will find loads of services that do this at the moment. I decided recently to take a stab at building my own one called sendonce.net. This service and may others like it, will take your secret message, encrypted it, store it on their servers for a short amount of time and give you a single access link to retrieve the secret. Usually the information will be deleted from the server once it has been accessed or if a short amount of time has passed since the data was stored.

In specific, sendonce.net takes your secret and sends it to our servers over TLS 1.2. From here we generate a new encryption key and encrypt your data with it. We then store the encrypted data in a transient in memory database where it will expire from memory in 10 minutes. We take the decyrption key and we return it to you in the browser as a single use link to reaccess your secret data.

Once this link is hit, the key is parsed from the URL and used to decrypt your secret message. The secret message is deleted from the server and its unencrypted content is returned to the browser. If you try to access the link again, there will be no data to access and you will get a 404. The same result will happen if you try to access the link after 10 minutes.

Wow! That sounds great, I'm going to start sending passwords for fun now!

Well... Let's not get ahead of ourselves here! Remember how I said that your secret is sent to the sendonce.net server? There is still a trust issue here, you have no idea that the secret isn't being stored somewhere before encryption. I've given you my word that it isn't, however, you have that to go on.

There is also another issue with sending the secrets to the server before encryption. Assuming that I don't store your secrets forever in plain text (which I don't 😬); it is still possible that the secret could get accessed in transit. Above I said that the secrets are sent to the server via TLS 1.2. Normally, it is understood that this is encrypted and secure between your browser and the server you are talking to. There are, however, certain network setups used in certain corporate environemtns where TLS is terminated at the network gateway. This essentially means that your traffic on the network internally is accessible and so your secret could possibly be accessed by your employer for example.

This is essentially a man-in-the-middle attack; services such as this can however tell you if you are operating in such a network environment. If you aren't, then this TLS expliot is not going to be a problem.

Hmmm... Maybe I won't use sendonce.net 🤔

In terms of risks, I probably wouldn't use this service had I not built it! However, I did build it, and I'm okay with trusting myself not to steal mine or other peoples secrets. So I am going to use it. What I said earlier still holds true, if you don't want something to be leaked on the internet, don't send it via the internet. Don't use email or Slack to send passwords or other secrets. However, if you really must, using a service like sendonce.net is a good step to making the process slightly more secure.

Happy NOT secret sharing!
- Ian