The problem with “secure” cloud storage

A lot of cloud storage providers take advantage of the uneducated to subtly sow lies. In this post we’re going to shine a light on their deception. In other words, we’re going to look at the common lingo used by providers when talking about their “security”, and then explain what these things actually mean.

“Your data is encrypted in transit using [blah blah blah…]”

Or alternatively, they might say: “encrypted using TLS [blah blah blah…]” (TLS => encrypted in transit)

If you ever go to a website that starts with “https://”, then the website was encrypted in transit. Half the Internet is already protected this way. Hell, this blog post was encrypted in transit.

So this just means your data was protected while it was being transmitted across the Internet, between their servers and your device. This means you can rest assured that the creepy guy in the corner of the coffee shop can’t read the data being transferred between your device and their server.

This is obviously important. However, the fact that this blog post was encrypted in transit should give you an indication as to how significant this is (in the context of secure cloud storage). What I’m saying is, it’s the lowest bar that one can possibly set. It’s the equivalent of the military requiring its applicants to be able to do a single pull-up.

Because, while your data may be secure while it’s transferring across the Internet, the next question is: What do they do with your files once the cloud storage provider receives them ?


“Your data is encrypted at rest using [blah, blah, blah…]”

Or alternatively: “military grade encryption using AES–256 [blah, blah, blah…]”

The term “at rest” is in contrast to “in transit”. In other words, we’re talking about how your files are stored on the hard drives of the server.

This is one of the trickiest phrases, because it’s usually used by companies that have zero interest in your privacy. That is, THEY want to be able to read your files. They just don’t want HACKERS to be able to read your files.

Consider Google. They obviously have an interest in reading your files. And your emails. And everything you do. Because you’re not the customer. The advertisers are. You’re the product.

Other mainstream providers have a similar conflict of interest. One of their primary concerns is search. It’s of utmost importance that large corporate clients can find a document that’s stored in the cloud, simply by typing a few words found in the content of the document. In other words, it important to the cloud storage provider that they can read and index your files (for searching purposes).

Now, obviously, being encrypted at rest is better than not being encrypted at rest. It’s just important to understand what this usually means:

  • you send the file to them (in a non-encrypted form)
  • they scan the file (for advertising purposes, or search indexing purposes)
  • they encrypt the file with a key (that they created)
  • they store the encrypted file on a hard drive somewhere
  • they store the key on a hard drive somewhere

It’s a little bit like locking your bike in your fenced-in backyard, and then storing they key in the backyard too. The thief has a little more work to do: jump the fence and find the key.

But in terms of privacy, this is usually just misdirection. After all, you’d be surprised what good hacking organizations are capable of. Assuming that a hack is even needed — social engineering might be far easier. Just find a disgruntled employee. Or perhaps a happy employee… who’s offered a large sum of money.


“Your data is encrypted client-side … [using ONLY your password]”

Or alternatively: “Zero knowledge encryption… [but all you need to login is your password]”

If you see this, you know the company has an interest in protecting your privacy. But perhaps they fell a bit short here. Consider this:

2-Factor Authentication (2FA) has become mainstream today. Think about all of those websites that send you an SMS code after you type in your password. (Or maybe they send you an email, or require you to use Google Authenticator, etc…) This has become so popular simply because it’s effective.

The rise of 2FA means that a very large number of organizations have taken a stand, and have declared: “A username & password alone is not enough to safeguard access to your account.”

Which highlights the shortcoming of “secure” cloud storage providers that allow you to access your data using only a username & password. It’s like they missed the last 5 years of the Internet.


How we do it at Storm4.

We wanted to take 2-Factor Authentication to the next level. So we started by researching how the big tech companies secure access to their accounts. And we were impressed. Lots of them are already using something like Google Authenticator. Facebook allows you to restore access to your account by getting verification from friends. And the continued R&D on this topic is fascinating. We read about retina scanners, facial recognition, voice recognition and more. There is clear indication that the identity security systems of these companies will vastly improve over the course of the next several years.

So we thought, “Let’s allow users to identify themselves by logging in using one of these large companies.” (I.E. Google, Microsoft, Amazon, Facebook, Twitter & 10 others.) “This way our users can benefit from the security systems implemented by these giants. Both today & tomorrow. HOWEVER, that won’t be enough to access their data. We will also require an access-key. One that only they possess.”

In other words, to access your data in Storm4 requires you to:

First: login using an “identity provider” that you previously picked

  • e.g. Google, Microsoft, Amazon, Facebook…
  • you can pick one that satisfies your security requirements
  • today this might mean 2FA
  • tomorrow it might mean voice + facial recognition

Then: provide your access key

  • this is a randomly generated key
  • generated on your device when you create an account
  • we don’t have this key, only you do
  • you can scan it using a QR code
  • or type it using a mnemonic representation

We’re calling it 2FA+ (short for 2-Factor Authentication + Access Key).

There are pros & cons of this approach. The pro is that security is increased by an order of magnitude. The con is that we require you to backup your access key. If you lose this (and you lose all the devices you’re already logged in with) then your data is gone. (Because we can’t read it, and we don’t have your access key.)

However, we firmly believe:

  • it’s better to err on the side of better security
  • users are capable of backing up their access key in a manner that is consistent with their security requirements

You can watch a demo of how this stuff works here.