Comment by tombrossman | Hacker News Reader

Comment by tombrossman | Hacker News Reader

Parent Full thread

> Did you host OwnCloud yourself?

Yes, I prefer to self-host anything I can. I'm lucky to have a gigabit FTTH connection and moving lots of data around is no problem. I still prefer to use a remote VPS because some things are best left to the pros.

> But you didn't trust the software with your files? In what way is the SeaFile solution you are running now more trustworthy?

Seafile has a much smaller attack surface (no PHP, MySQL not required, etc) and handles the client-side encryption itself. We are discussing degrees of trust here, so while I was happy to trust ownCloud and the VPS to be there for a request, and to not corrupt my data, I didn't trust that my sensitive data was safe if the server was compromised. EncFS was a workaround, but it cluttered up Nautilus with extra drives since every encrypted directory had to be mounted as a drive. Now I'm comfortable trusting Seafile to do all that because an attacker would need to compromise both my VPS and my local machine to gain access to sensitive data. This is orders of magnitude less likely and for me is an acceptable risk, especially considering the simpler software stack.

And I'm definitely checking out radicale, thanks for the tip. If it does contact photo sync (annoyingly not currently supported my FastMail CardDAV) I'll give it a try.

> Seafile has a much smaller attack surface (no PHP, MySQL not required, etc)

ownCloud does run a successful Bug Bounty program and is paying for security bugs: https://hackerone.com/owncloud

Also I have published a blog post elaborating why CVEs are not everything when it comes to comparing the security of products: https://statuscode.ch/2015/09/ownCloud-security-development-...

Furthermore please take a look at https://seacloud.cc/group/3/wiki/security-records/. Not using PHP doesn't make everything more secure magically, neither does using PHP make things more secure.

Thanks, good to know.

The ownCloud Android client required duplicate copies of all the photos & videos (the original plus a copy in the ownCloud folder) which filled up storage on my phone too quickly. Once this is sorted I might try it again, even if only for the calendar and contacts. It has many features but I just don't need most of them.

There is a pull request with a fix for the Android issue you describe: https://github.com/owncloud/android/pull/1168 Would be very helpful if you can test it! :)

When I was reviewing alternatives, syncany's web page claimed that seafile has a poor security record: https://github.com/syncany/syncany/wiki/Comparison:-Syncany-...

I'm not sure how seriously to take this.

I nearly went with Syncany, they were a very close second but they are still in alpha, plus they have no mobile apps (yet). I really like being able to take a photo with my phone and have it sync to my computer.

Development on Seafile is very active and they are transparent about security issues. I don't think it is poorly written but maybe a third-party audit like Truecrypt did is a good idea.

Here's their 'Records of security issues' page: https://seacloud.cc/group/3/wiki/security-records/

> Here's their 'Records of security issues' page: https://seacloud.cc/group/3/wiki/security-records/

Just take a look who reported their recent issue allowing a lot of attack vectors. (more than they mentioned though) :)

Actually if somebody had a local user account themselves they could bruteforce the secret key in seconds. And SeaFile has additionally modified the default Django components making it more insecure: https://github.com/haiwen/seahub/commit/7cdb70368aa7acbf0546...

By the way, ownCloud does run a Bug Bounty: https://hackerone.com/owncloud

On mobile so please excuse me if I missed something subtle, but what's more insecure about this change? From what I know constant time compare protects against timing side channel attacks, so isn't it improving security here?

That was actually the part where they partially mitigated the vulnerability with. So before it was more insecure. The green one is the "fix" :)

The constant time comparison is pretty irrelevant here. Check https://github.com/haiwen/seahub/commit/7cdb70368aa7acbf0546..., basically a valid password reset token in default Django requires an attacker to know:

- Primary Key of the user (User ID)

- Hashed version of the user password

- Timestamp of the last login (1 second accuracy)

- Number of days since 2001-1-1 converted to base 36

- The configured SECRET_KEY

Basically except the configured SECRET_KEY and the hashed version of the password everything is known to an attacker. And even if an attacker knows the SECRET_KEY they would not be able to generate a valid token as the old password hash is required.

However, Seafile has removed the hashed password out of their version of "tokens.py". This means that if somebody knows the SECRET_KEY they could create valid password reset tokens. That the initial SECRET_KEY was basically generated by `str(random.randint(0,100000))` did make this all much more worse… (https://github.com/haiwen/seahub/blob/b6f8935c0f355cc70145f9...)

Bad thing about this is that this basically makes a lot of old Seafile instances insecure unless they get a new SECRET_KEY. They did somewhat tell users to regenerate it within a forum post and some wiki page (https://seacloud.cc/group/3/wiki/whats-new-in-the-next-versi...) but that's not really a good way to spread awareness…

Thanks for taking the time to explain... Sorry to nitpick, but I'm trying to get things clear.

your original comment pointing to the commit said

> And SeaFile has additionally modified the default Django components making it more insecure

So I was under the impression that this commit was making things worse, not better. Thanks for clarifying that this was already fixed in this commit, rather than introduce a vulnerability. It looks like they added the hashed password on the diff to mitigate this issue - unless I am missing something here? Can you explain why they "partially mitigated the vulnerability" here? is there still some gap that they've missed?

I'm not underestimating the vulnerability, or the fact that it was there in the first place. Just trying to get a full(er) picture.

I've had a read through this, and some other places where insecurity of Seafile is exposed/discussed/fixed. I agree that the overall impression I'm getting is that they're not security experts, and security could have definitely been better designed or taken into account in the first place.

I still think they're trying to do their best, and fix problems and improve. I hope for their and their users' sake that they can get some security-dedicated contributors (mostly to prevent bad things in the first place rather than fixing them later on). There's always more that can be done, but I'd like to give them the benefit of the doubt here and have faith that things will be better in the long run. Having a (robustly) secure, open-source dropbox replacement is a good thing. I think that's their aim, even if they are some times misguided.

disclaimed: I'm not even a user of Seafile, let alone know much about its codebase. It's the first time I hear about it. I was just curious about the security aspects of their product in light of some criticism here and on github etc.

Reply on news.ycombinator.com