4 ms·

> I also had to set up EncFS on my local machines for client-side encryption of sensitive files because there was no way I was trusting that to ownCloud server-

> I also had to set up EncFS on my local machines for client-side encryption of sensitive files because there was no way I was trusting that to ownCloud server-side. Did you host OwnCloud yourself? But you didn't trust the software with your files? In what way is the SeaFile solution you are running now more trustworthy? > I'm still looking for a good self-hosted CalDAV/CardDAV option that doesn't require PHP or MySQL, but as this data is less sensitive I'm happy to trust it to FastMail for now. http://radicale.org/ http://radicale.org/ is exactly what you are looking for.

deleted 11y ago
[deleted]
tombrossman 11y ago
> 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.
- pjc50 11y ago
  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-vs.-X https://github.com/syncany/syncany/wiki/Comparison:-Syncany-... I'm not sure how seriously to take this.
  - tombrossman 11y ago
    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/ https://seacloud.cc/group/3/wiki/security-records/
    - LukasReschke 11y ago
      > Here's their 'Records of security issues' page: https://seacloud.cc/group/3/wiki/security-records/ 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/7cdb70368aa7acbf05461e22e83278b00c2036c8 https://github.com/haiwen/seahub/commit/7cdb70368aa7acbf0546... By the way, ownCloud does run a Bug Bounty: https://hackerone.com/owncloud https://hackerone.com/owncloud
      - gingerlime 11y ago
        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?
        LukasReschke 11y ago
        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/7cdb70368aa7acbf05461e22e83278b00c2036c8#diff-31b2676ed825badbf63e5be98fb54c25R68 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/b6f8935c0f355cc70145f9c2706cc99512e39ac2/tools/secret_key_generator.py 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-version-4-3/ https://seacloud.cc/group/3/wiki/whats-new-in-the-next-versi...) but that's not really a good way to spread awareness…
- LukasReschke 11y ago
  > 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 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-over-the-years/ https://statuscode.ch/2015/09/ownCloud-security-development-... Furthermore please take a look at https://seacloud.cc/group/3/wiki/security-records/ 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.
  - tombrossman 11y ago
    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.
    - jancborchardt 11y ago
      There is a pull request with a fix for the Android issue you describe: https://github.com/owncloud/android/pull/1168 https://github.com/owncloud/android/pull/1168 Would be very helpful if you can test it! :)
deleted 11y ago
[deleted]
StavrosK 11y ago
Thanks for radicale! I switched to it from Google Calendar and Contacts. The git integration is amazing.

deleted 11y ago

[deleted]

tombrossman 11y ago

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

pjc50 11y ago
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-vs.-X https://github.com/syncany/syncany/wiki/Comparison:-Syncany-... I'm not sure how seriously to take this.
- tombrossman 11y ago
  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/ https://seacloud.cc/group/3/wiki/security-records/
  - LukasReschke 11y ago
    > Here's their 'Records of security issues' page: https://seacloud.cc/group/3/wiki/security-records/ 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/7cdb70368aa7acbf05461e22e83278b00c2036c8 https://github.com/haiwen/seahub/commit/7cdb70368aa7acbf0546... By the way, ownCloud does run a Bug Bounty: https://hackerone.com/owncloud https://hackerone.com/owncloud
    - gingerlime 11y ago
      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?
      - LukasReschke 11y ago
        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/7cdb70368aa7acbf05461e22e83278b00c2036c8#diff-31b2676ed825badbf63e5be98fb54c25R68 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/b6f8935c0f355cc70145f9c2706cc99512e39ac2/tools/secret_key_generator.py 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-version-4-3/ https://seacloud.cc/group/3/wiki/whats-new-in-the-next-versi...) but that's not really a good way to spread awareness…
LukasReschke 11y ago
> 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 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-over-the-years/ https://statuscode.ch/2015/09/ownCloud-security-development-... Furthermore please take a look at https://seacloud.cc/group/3/wiki/security-records/ 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.
- tombrossman 11y ago
  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.
  - jancborchardt 11y ago
    There is a pull request with a fix for the Android issue you describe: https://github.com/owncloud/android/pull/1168 https://github.com/owncloud/android/pull/1168 Would be very helpful if you can test it! :)

deleted 11y ago

[deleted]

StavrosK 11y ago

Thanks for radicale! I switched to it from Google Calendar and Contacts. The git integration is amazing.