> "First it is important to understand what this encryption module is actually supposed to do and understand the threat scenario. The encryption provides no security against a malicious server operator, because the encryption happens on the server. The only scenario where this encryption helps is if one has a trusted server that is using an untrusted storage space."
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 just want to add a big emphasis to "YOUR OWN CRYPTO" with Dropbox. Stuffing data into Dropbox without encrypting it first for example with VeraCrypt is a bad choice. Even Dropbox says their own employees "need" access to your data "occasionally". (Also, I meant to upvote you but I fat-fingered it on my phone, sorry!)
VeraCrypt or other FDE-like tools (that are meant to be used on actual drives or their imitations using a file-backed device) are not so great idea for use with Dropbox or alike file/object storages. Here's why: http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
Is there a client side encryption tool that works with Dropbox and is usable by non technical people (plus for being available on both Windows and Mac)?
I personally use encfs to create a partition within Dropbox, but I don't see that being easy to setup and manage...
Cryptomator [1] looks like it fits the bill for what you described. Seems to use a transparent mapped virtual WebDAV drive to make it usable. From my experiments at least, it seems it should be usable by non-technical people without significant demonstration or training.
Yes, maybe I should've made this emphasis stronger in my comment. Also I didn't meant to say that using owncloud is worse than using dropbox in security terms - but you should use your own (client-side) crypto either way if you care about data security.
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.
I also use EncFS - on Dropbox/GoogleDrive/JottaCloud - but be aware it's got known flaws, don't rely on it if your data might be of interest to a nation state or high level law enforcement: https://defuse.ca/audits/encfs.htm
For those who aren't afraid of manual control (which can be a pro or con) and a bit cryptic CLI invocations, I'd say - give git-annex a try.
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.
What seems truly scary is how little the developer seemed to care about those security bugs (following related issues, you also find an exploit, SQL injection and so on) and being dismissive of the guy who found them.
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
Bittorrent Sync does end to end encryption, and you can set up an encrypted read-only peer that never sees any plain text. The encrypted peer does contribute to the swarm.
This is a really great writeup. But CTR+HMAC is, in fact, a composed authenticated encryption mode. If you have a working system with CTR+HMAC, I'd recommend against spending effort switching to GCM, which is actually harder to get right.
I thought AES-GCM was on its way out? Isn't poly1305-chacha20 what we should use now, given that it's quite a bit cheaper in terms of cost, and the keys are much smaller (32 bytes)?
I definitely personally prefer ChaCha/Poly to GCM, but GCM is unfortunately quite popular right now; of the unencumbered AEADs blessed by NIST, it's very performant and thus widely implemented.
Still recall running across a vendor that was hashing credit cards using MD5. Asked them why, and their response was that they were PCI compliant. Called the main PCI line, asked them if MD5 hash was an acceptable way to store credit cards securely, and the answer was yes.
How many bit of entropy are in a credit card? I ran the numbers a few years ago but don't remember now. Well within a very small rainbow table in any case.
You have 10^15 possible values from a 16-digit CC number (due to Luhn's algorithm). The first 6 are for the issuer/bank; if you know that, you have 10^9 or about 30 bits of possible values.
Stores in our college had them being sent out in plain text. They wouldn't change to secure equipment and would occasionally plug the internet into the college servers where we watched them...
So what is the implication of this? The major reason to use the crypto module is that my users can add their google drives to owncloud and its encrypted on there.
If you want to go along with owncloud (and I don't know a proper alternative) there's not much you can do then upgrading to Owncloud 9 and hope that the fix was done right. In the meantime you could encourage your users to use their own client-side encryption while giving up the idea of an easy setup.
There are some community activities to implement client-side encryption. But as far as I know there doesn't exists any running code at the moment. So don't expect to much in the next few months.
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.
As always it is not black and white. It depends on your threat model. If you just want to make sure that Google can't read your content (which was the original intention of ownClouds server-side encryption) then everything is fine. Also with older versions. But if you fear that Google might not only read your data but manipulate it then I would suggest to upgrade to ownCloud >= 9.0. But keep in mind that the files only get encrypted the new way the first time you touch them. ownCloud will not migrate all your existing files to the new encryption which includes the signature.
Ach, look at it this way. If it was in a proprietary product, you could sleep safely because nobody would ever tell you that your data was insecure. ;-)
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).
They mention that Windows will still execute the DOS stub when it can't find a PE header. Is this still true in 64-bit Windows? I would think that the DOS stub would be 16-bit code, which is not supported anymore in 64-bit Windows.
45 comments
[ 0.18 ms ] story [ 109 ms ] threadWhile 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...
[1] https://github.com/cryptomator/cryptomator
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
https://github.com/haiwen/seafile/issues/587Enough 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.
(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).
https://github.com/jedisct1/libsodiumWhats 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).