Hacker News Reader

Comment by nbpoole | Hacker News Reader

So, the FBI has a copy of Instapaper's complete database and a copy of their website code. The database includes:

- Salted SHA-1 hashed passwords for Instapaper

- Encrypted passwords for linked Pinboard accounts (with the encryption key stored in the website code)

- OAuth tokens for linked Facebook/Twitter/Tumblr accounts (and presumably also the secret keys used by Instapaper to use those tokens).

That's (potentially) a lot of personal information.

View on HN

Perhaps even more important, they have a list of hundreds (thousands?) of pages I thought were interesting enough to read later. Seems like a fine base from which to build or enhance profiles of thousands of citizens.

Even better, they can use that information to build or enhance profiles WITHOUT getting any kind of judicial approval or oversight. Yay, Patriot Act (not).

As a real practical question out of curiosity: how would you design their system differently so unauthorized people having only your hard drives couldn't get any data at all?

You could always hash the e-mails, although this would make resetting your password impossible.

How much data do Facebook's OAuth tokens contain? By looking at one, can you tell that it's linked to Pavel Lishin's account?

Would splitting the data in half work?

I mean literally cutting the data sent into two pieces and each piece entering a different database server in a different country. Then, when requested, pulling both pieces and sending them to users who patch them together with client side script...?

There has been some academic work on this (CIDR'05), but I'm not sure if it has been used in practice.

http://ilpubs.stanford.edu/659/

Thanks, printed it off, will try to read on the train.

Sounds like a good use case for Instapaper :P

Might not want the FBI to know he read the article if they come back for a "followup visit"

So, basically a RAID array? You'd have to have a fair amount of redundancy, to make sure that if your Dystopiastan server gets taken down, your servers in Freedomia and Libertania have enough data to continue serving your users. (And yet you can't have so much redundancy that a single country could rebuild your database if they take enough servers.)

Not to mention, latency issues would be a problem.

Yes, OAuth tokens contain the Facebook id of the user. It is unlikely that this would matter since session tokens (required for most permissions) expire after an hour (no reason to store those) and sessionless tokens are per-application not per-user.

However, obtaining the application credentials for Instapaper would allow you to limited access to a user account on behalf of Instapaper. Since the credentials for doing this are per-application, Instapaper would likely store your Facebook id in their database. Given a Facebook id, you can easily see the account name by visiting https://graph.facebook.com/$id.

>You could always hash the e-mails, although this would make resetting your password impossible.

Not really - everywhere I've gone has asked me for my email to send me my password. Same principle as with passwords: enter your email, we hash it, if it matches a hashed email in the DB, we send a 'reset' email to the address you entered.

Full-disk encryption. You enter the key whenever the system needs to be rebooted. I know at least one company that does this with all of their US-hosted servers.

And not servers hosted in other countries? I'd be very curious to hear the thought process behind that decision.

Perhaps all their employees live in the US, so they consider it not worth the trouble to fly someone to Indonesia whenever a server in Jakarta needs rebooting.

It's not necessary that they have physical access in order to do that, though.

This would only be protection against thieves that steal your harddrives, if the US government had your drives they can legally compel you to divulge your password.

There are systems you can use to defeat this. One password decrypts the drive, another wipes it.

If there was a court order for the decryption keys for your drive and you gave them a key that destroyed it, you would almost certainly be found guilty of deliberately destroying evidence.

If they could prove that that's what you did.

The company in question is actually located outside of the US, and so are all employees who have access to the key. It keeps its servers in the US only because of issues with cost and latency, I think.

On my collocated server, I use encrypted LVM for all of my filesystems (except /boot, of course). On my next hardware upgrade cycle, I'm going to install a USB gyroscope (inside the chassis, using one of the front USB headers) and write a daemon that will issue a `umount -lfa && halt -n` if the box is ever moved.

Note that this isn't simply to keep prying eyes off my data; I live near an overdue earthquake fault line. When it does finally give, I should have a (slightly) better chance of the machine coming through intact.

Shouldn't you throw in a `sync` before halting?

If you do that, I would change && to ; on the basis you want the halt no matter whether the umount succeeds or not.

If the hardware is in hand then I don't see any practical way to protect the information. The only way that works is to not store the information in cloud servers.

   The only way that works is to not store the information in cloud servers.

Where would your servers be safe? Colo? No. In your basement? No? In another country? Possibly, depends. At HavenCo? Maybe.

I was talking from a user's perspective. As a user your data is safer on your local machine than on a cloud server run by who knows who.

Presumably most or all of these services will let you rotate your secret key, and Instapaper will do that. Assuming it was done rather quickly, then there would be no practical risk of unwanted access for any of the OAuth accounts. If the services don't let you rotate your secret key, well... they probably should.

Reply on news.ycombinator.com