Pwncloud – Bad crypto in the Owncloud encryption module
blog.hboeck.de
blog.hboeck.de
While it's a good finding that even in this specific scenario the crypto-module is screwed up, I think an even bigger problem is that most people hosting owncloud either don't know or care about all threats not covered by this scenario.
I heard stuff like "Owncloud has crypto, so it must be secure." from people hosting owncloud on server they didn't have much control (especially physically) about. It's not only the "malicious server operator" but everyone with administrative access (legitimate or not) to this server.
But unfortunately I don't know a selfhosted easy-to-install-and-use alternative with strong client-side encryption, which boils down to: Dropbox (or any other cloud storage provider) with client-side encryption of your own choice is more secure than owncloud with only the crypto-module.
I personally use encfs to create a partition within Dropbox, but I don't see that being easy to setup and manage...
For myself I use my selfhosted owncloud (running on a cheap VPS) with EncFS, encourage other users on that server to use client-side encryption as well and never lied about how secure their data is when they decide not to. But this isn't so easy as it should be.
It works with multiple remotes (hubiC, OneDrive and SFTP) flawlessly for me.
A basic file management is well automated by git-annex-assistant (e.g. just moving a file to "archive" directory makes sure necessary number of remotes have a copy and a local one is then removed, etc etc.), but the initial setup has to be done by a tech-savvy person who had spent some time reading the docs.
I just wanted to point out that as long as you're not in full control of the server hosting Owncloud (and not connect your Owncloud to third party cloud spaces) you've to care about your own client-side crypto like on any other cloud provider (self hosted or not). So there's nothing special about Dropbox - but also not so much special in security terms about Owncloud.
Anyway I would still recommend using Owncloud over any other cloud storage provider if you're able to host it or know someone hosting it. But you should consider the security implications if you care.
Easy to install and to upgrade (except a small glitch in the last upgrade).
For the community version, the source code is here : https://github.com/haiwen/seafile (see others haiwen projects).
The Android client could be improved, but it does the job.
https://github.com/haiwen/ccnet/issues/35
/* truly random sequece read from /dev/urandom. */
static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7, 0xcc, 0x26 };
Enough to understand if people writing this software know how to apply cryptography. This was 2 years ago, so I hope they improved.
Incredible that people will actually do this in production code. I don't understand a lot about cryptography, and even I know this not a good idea.
> We don't roll our own crypto.
> There are two parts of the code base in which "we roll our own crypto": the transfer protocl and encrypted library.
That's just ridiculous.
About metadata : https://seacloud.cc/group/3/wiki/seafile-roadmap.md there is one line saying "Ability to encrypt all data by server key. Key has to be generated by administrator" but it's not on the changelog page ( https://seacloud.cc/group/3/wiki/Server%20ChangeLog.md )
Seafile stores a lot of metadata in clear text (including filenames): https://github.com/haiwen/seafile/issues/350
The developers know about it, the issue is 3 years old, this huge limitation is still not reflected on their documentation.
An attacker who obtains a copy of the encrypted library without the key can:
- read the complete list of directory and file names.
- know the size of every file
- know which files share some of the same information
- see the history of who changed each file, when, and what byte ranges were altered(No, SyncThing, despite its greatness is not it. The sharing model is too complex for the average user.)
Also, the code for chacha is easily available.
You'll more than likely make a mistake.
Libsodium offers both (but AES-256-GCM is only available if you have hardware support for constant-time implementations).
crypto_aead_chacha20poly1305_encrypt()
crypto_aead_chacha20poly1305_decrypt()
crypto_aead_aes256gcm_encrypt()
crypto_aead_aes256gcm_decrypt()
Whats the recommended course of action?
In general I want to note that client side encryption is great. I also like and use it in many areas. But you also have to keep in mind that it will make most of the web interface and it features useless. Personally I run my ownCloud in my basement. The connection to the server is secured by https and the hard disc is encrypted with LUKS. In this case it doesn't make sense to me to add additionally server-side or client-side encryption.
The first step is always to check your threat model, your setup and your requirements to see if you really need server-/client-side encryption.
We pay researchers and others to check ownCloud for security issues (the writer of this post got paid by us), we have security checks done by various companies etcetera - see https://owncloud.org/blog/hackerone-case-study-on-owncloud/
But it is, of course, still insecure because nothing is secure. I only can say we're pretty much the project with the best security processes and most attention towards security in the file sync and share space. From the open source ones, at least - you'll never know about the closed ones, they keep things hush-hush. Protecting your sleep (not your data).