
Pwncloud – Bad crypto in the Owncloud encryption module - Artemis2
https://blog.hboeck.de/archives/880-Pwncloud-bad-crypto-in-the-Owncloud-encryption-module.html
======
schlowmo
> "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.

~~~
fapjacks
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!)

~~~
drdaeman
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/](http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/)

~~~
giovannibajo1
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...

~~~
dublinben
EncFS is specifically not safe to use in situations where an attacker has
multiple versions of your data.

------
nxzero
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.

~~~
mentat
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.

~~~
CiPHPerCoder
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.

------
tptacek
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.

~~~
sargun
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)?

Also, the code for chacha is easily available.

~~~
CiPHPerCoder
Also: Don't implement chacha20-poly1305 or AES-GCM yourself, unless you're a
crypto expert.

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()
    

[https://github.com/jedisct1/libsodium](https://github.com/jedisct1/libsodium)

------
gpvos
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.

~~~
gpvos
Indeed it isn't, at least according to Wikipedia:
[https://en.wikipedia.org/wiki/DOS_MZ_executable#Compatibilit...](https://en.wikipedia.org/wiki/DOS_MZ_executable#Compatibility)
says: _64-bit versions of Windows cannot execute them._

------
nickik
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.

Whats the recommended course of action?

~~~
schlowmo
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.

~~~
nickik
Im already running the newest version. I hope they approve on it in future
versions. Client side crypto would be cool.

~~~
BjoernSchiessle
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.

------
starts
That's quite worrisome..

~~~
jospoortvliet
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. ;-)

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/](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).

