Some reservations about SpiderOak security.

December 8, 2013

I am looking for a secure cloud service. One of the options I considered was SpiderOak. However, after reading the following explanation about how the mobile version works, I started to get worried.

[..W]hen accessing your data via the SpiderOak website or on a mobile device you must enter your password. The password will then exist in the SpiderOak server memory for the duration of your browsing session. For this amount of time your password is stored in encrypted memory and never written to an unencrypted disk. The moment your browsing session ends your password is destroyed and no further trace is left.

The instance above represents the only situation where your data could potentially be readable to someone with access to the SpiderOak servers. That said, no one except a select number of SpiderOak employees will ever have access to the SpiderOak servers. To fully retain our 'zero-knowledge' privacy, we recommend you always access your data via the SpiderOak desktop application which downloads your data before decrypting it locally.

I explained earlier that for web-based sharing with others, many secure cloud services effectively provide a backdoor. But this is even worse because apparently SpiderOak can provide the content of a file solely based on your password.…

So I started looking for details. These were not hard to find (and in all honesty it is laudable that SpiderOak provides this information prominently on its website in simple language). It turns out that SpiderOak security works as follows.

The secret that keeps your data accessible to you alone is your SpiderOak password, which is never transmitted to SpiderOak in its original form. This means you alone have responsibility for remembering your password or 'Password Hint' (which you can create to help you remember.) If the password is forgotten, there's nothing anyone can do to make the encrypted data readable to you again.

When you first run the SpiderOak software on a computer, a series of strong encryption keys are generated. The keys are themselves encrypted with your password and stored (along with your backup data) on SpiderOak servers in their encrypted form.

I have some reservations about this. Using this method of encrypting keys with a password leaves several security problems. First of all people pick horrible passwords that are easy to guess. If the password-encrypted keys are stored on the server, they can be brute-forced there (one can only hope that the encryption of the keys with a password is such that it is not trivial to see whether a guess of the password is correct because the use to decrypt returns a meaningful result). This is even the case if you never access your data using browser or a mobile app. If the SpiderOak servers are ever hacked, this brute-forcing can be done by outsiders.

Even worse is that in certain cases the cleartext password is sent to SpiderOak to decrypt the encryption keys on their servers. This means that whenever SpiderOak is ordered by the authorities to hand over the keys (or the password), it can (and must). They just have to wait until you access your files with a browser or a mobile app. Note that a security conscious user that uses a very strong password for SpiderOak, will suddenly have lost control over this password. This is a risk if this password is also used to access other (sensitive) services.

This method is probably chosen to allow users to easily access their files from a device that is not their own. In that case, a browser is all that is available. But the fact that SpiderOak uses the same insecure method for their mobile apps is inexcusable. It would be quite easy to ensure that also for the mobile app the decryption is always done locally. The only hard part is to design a secure way to get the keys from your PC to your mobile device.

A better way (one used by TeamDrive), is not to encrypt the encryption keys with a password, and to not store these keys on the server. They should stay local, on your own PC or mobile device. (If you share a file or folder, a separate key must be used for encrypting it, and only this key should be shared and again stored locally on the devices of the people the data is shared with.) The downside of this approach is that you cannot access your data in the cloud using only a browser (unless perhaps using special plugins), because the browser typically cannot access the decryption key. And the decrpyiton key is not even present on any other device than your own. Similarly, you cannot share access to your files by sending a simple link to your friends. Once again we see that proper security comes at a cost in terms of usability. Which is a pity.

In case you spot any errors on this page, please notify me!
Or, leave a comment.
AD
, 2013-12-08 21:42:59
(reply)
Benedict
, 2014-07-20 11:08:25
(reply)

Wrong! A password on a mobile device or desktop is unsafe if the operating system is proprietary (windows, iOS) or there is a “secure” boot loader or a network based upgrade.

D
, 2016-02-26 07:40:13
(reply)

It’s not SpiderOak’s fault if you use a bad password.

If the password is not stored on the server in encrypted form but is kept only locally, then:

  1. If you install spideroak on a second computer, then your password is not enough to cause your files to be accessible on that second computer. You will need to hand copy your key from your first machine and move it to your second machine.

  2. If your data is on a device that is lost, and only on that device, then the key, encrypted with a password or not, is also lost. So while your data may be in the cloud, you’ve lost any means to decrypt it. Getting around this means some complicated process of users backing up their keys. I don’t think that’s what people want. I certainly prefer using a good password and leaving an encrypted key in the cloud.

  3. You will not have access to your files through a web browser under any conditions, including emergency. Spideroak is very clear that if you want the files directly from the server, then you will have to give the password to the server. That’s natural enough. The only alternative is to use some kind of javascript or in-browser code to download the key to the browser and decrypt it there, along with the file, thereby keeping the password local; but that’s not particularly secure either.

As for a mobile device, I don’t know but am guessing that there may not be enough horsepower to decrypt the files on the fly. That’s why it’s different from a desktop/laptop and more like accessing it through a browser.