

Other people's data - georgebashi
http://blog.tidy.io/2012/10/08/other-peoples-data.html

======
tptacek
I don't use services like this (I can't really use cloud backup systems of any
sort) and so I'm not meaning to pick on tidy.io when I say this, just to help
them do this page better:

* It's all well and good to serve the login page from HTTPS, but if you want to lock your site down to HTTPS, set HTTP Strict Transport Security to lock the site to HTTPS in the browser.

* It doesn't look like you set the Secure flag on your cookies, meaning that anyone who can spoof <http://TIDY.IO> can capture session cookies.

* If you're serious about protecting my data, how much can you really tell me about the security of KISSMetrics, of GetClicky, or of the Google Font API server? You delegated to each of those third parties control over your DOM and thus of my data.

Taking the assertions of the page a little further:

* I'm glad you see the light on not inventing your own crypto library... but if you're encrypting data, what library did you use? Did you use a library that can't easily be misused, or did you use something like OpenSSL?

* Can your administrators theoretically decrypt data on the server? Tarsnap's administrator can't --- but then Tarsnap isn't a web application.

* How is your site administered? Can admins SSH into production boxes over the public Internet? Do you have passwords anywhere? Have you deployed 2-factor authentication? Do you have an HTTP/HTTPS admin console application somewhere? How is it accessed?

* How is email handled at TINY.IO? Does all your TINY.IO-related business go through TINY.IO mail, at someplace like Google Apps? Or do you have admin accounts for your personal email addresses? Are your email addresses password protected or 2-factored protected?

* Where would I go to report a vulnerability in TINY.IO? Has anyone ever done that? Is there some list of people you've thanked for doing so?

I wish I could say these things were just pedantic, but they've all mattered,
often quite a lot, in past incidents.

The elephant in the room question on all services like this is simple and hard
to answer effectively: assume that there is a critical vulnerability in your
application (very very very talented developers have managed to ship remote
code execution before) --- what mechanisms are in place to ensure that the
worst-case vulnerability doesn't provide an attacker with access to my Dropbox
data? The answer can't be "CircleCI".

~~~
almost
Thanks for these points. I've set the HTTP Strict Transport Security header
and session cookies are now HTTPS only, these are definitely good very good
ideas. While I do think that those services can probably be trusted it's
always good to reduce any dependencies on 3rd parties so I'll definitely
consider moving the stat logging server side.

To answer your other questions:

* I used PyCrypto which certainly isn't as fool proof as I'd like but seems to be the best option available to me.

* Admins can decrypt the data by the nature of how the service works, Tarsnap requires you download and run an application yourself so is for very different types of users

* We use SSH certs and no admin is accessible to web users

* We do use Google Apps for email, and we do have two-factor set up

* tidy.io hasn't been up long enough to get vulnerability reports but if we do we will handle them responsibly and definitely give the finder thanks and credit. We do need a proper statement of this on the site though, I'll sort that out!

~~~
tptacek
It is very easy to write bad crypto with PyCrypto (it is an interface on
pretty much the same level as OpenSSL). As a Python developer, you have access
to Keyczar, which is what you should use instead of PyCrypto. The number of
questions you'd have to address about your PyCrypto cryptosystem to make that
point an asset instead of a liability (to savvy readers) is too large for the
page you're trying to write.

You've exposed SSH to the Internet? Your SSH endpoints have routable IP
addresses? How many of them do you have? If you've deployed this on EC2, you'd
be better off moving all your admin to a VPN connection, so that any server
you'd SSH into has a 10-net address.

------
olivercameron
Having worked with Thomas before, I know he has extraordinary attention to
detail when it comes to code quality and security. I'd certainly trust my data
in tidy.io.

One feature I wish services like this had is an incredibly simple way to
backup a large folder to Glacier/S3 and then retrieve it just as easily. I use
Dropbox for things that change on a frequent basis, and I want to use Glacier
to archive everything else. Would be happy if anyone knew of such a service,
but for now, I'll be using tidy.io.

------
nc17
These are good points. However, as a user of Dropbox I just don't care if they
encrypt my data or not. If I back up anything sensitive, I encrypt it myself.
For stuff that's not that private (e.g. pictures that I've shared) I assume
that anyone at Dropbox could look at them.

~~~
andybak
It's more than just your data. The other service similar to tidy.io that
recently launched managed to leak people's private AWS keys.

------
richardwhiuk
Irony: Proclaiming 'HTTPS everywhere' when the webpage it's on doesn't use
HTTPS.

~~~
nc17
"It goes without saying that all pages shown to logged-in users should be
served over HTTPS"

You're not logged on to that page, it's a blog. There's nothing to gain by
serving it over https.

~~~
mentat
"nothing to gain" has interesting intersections with domain-wide cookies when
mistakes are made.

------
barcoder
Good to read a blog post like this after seeing IceBoxPro's attempt at
security.

