I have written about the fuzzy mud puddle test before. It turns out it is misleading. Even a cloud storage provider that fails this test may still be able to decrypt your files without your explicit cooperation.

The problem is that many cloud storage providers, including more secure ones like SpiderOak and Wuala that implement client-side encryption, offer the option to share access to a file using a URL. Anyone with the URL can access the file over the web. From a usability point of view this is great: there is no need to install client side software. You simply (securely!) email the URL to your friends, and that’s it. Unfortunately, it’s also a security risk.

The URL sharing method works as follows. The URL typically starts with the server name of the cloud service provider. It is the cloud service provider itself that handles the request to give your friend access to the contents of the file. The URL also contains an access key to the file, that allow its contents to be decrypted. The web server of the cloud provider uses this key to decrypt the file.

And this is where the problem lies. By sharing a URL with a friend, the cloud service provider learns the access key as soon as your friend clicks the URL. This is against the ‘zero-knowledge’ (really a horrible abuse of a technical term by the marketing department of SpiderOak BTW…) pledge of the cloud service provider and totally defeats the point of applying client side encryption: the cloud service provider should never learn the encryption key. And with this U-turn, it does!

(Update: the extent of the compromise depends on the exact way the cloud service provider implements encryption and how it enables access using the access key. In some cases, the access key may only provide the decryption key for the file being shared, and no other files. In other cases it may reveal the decryption key for all files in the same folder where the shared file resides.)

Sure, the cloud service provider will claim they never store the key, and don’t log the URLs their servers receive. But the problem is this: they may at some point be forced to do so, regardless of their promise. Like the US government did with major US web companies, telcos and Lavabit (the secure email provider Snowden used).

Conclusion: if you really want a secure cloud service, use one that doesn’t offer the option to share access by passing around URLs. The browser is not a safe place to access sensitive files to begin with. And even though they (probably) mean well, the cloud service provider really cannot guarantee that they will not, at some point, store the access key and hand it over to the government. After all, they have to comply with the law…

Update (28-10-2013, 15:49 CET): The URL could contain the access key after a # sign in the URL. In that case the access key is not sent to the web server. However, malicious javascript code served by the webserver of the cloud service provider (CSP) still has access to this part of the URL (and thus the access key) and can upload it to the CSP regardless. As commented below, this is also possible if you use client side software provided by the CSP. But in that case you have more control, in that you can refuse to install updates. Better still: use a cloud provider who provides an open API and allows any open source client to connect to your data over that API.