The FBI stole an Instapaper server in an unrelated raid • Hacker News Board

Re: The FBI stole an Instapaper server in an unrelated raid

#21

Post by imrehg » Thu, Jun 23, 2011, 5:39 PM UTC

nbpoole wrote: post #4

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 (potentiall…

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?

Re: The FBI stole an Instapaper server in an unrelated raid

#22

Post by pavel_lishin » Thu, Jun 23, 2011, 5:41 PM UTC

cheald wrote: post #13

yuvadam wrote: post #6

I'm trying to think of an analogy which can explain why this might be reasonable from the FBIs perspective. Suppose you were using a shared storage space (shared servers, or server farm) with several other dudes. One of them is a drug dealer. One day the police/FBI decide to raid the storage space since the drug dealer has been using it to store illegal drugs. Is it not reasonable to consider this collateral damage (…

It is not reasonable if the FBI does not have a warrant for your servers(/storage space). Instapaper is completely right to call this "theft". If his servers are included in the warrant because they were suspected of housing whatever it is the FBI was after, and the court granted the FBI the right to seize them, then yeah, it's reasonable. If he was sharing a physical machine with the bad guys, then yeah, sorry, that…

Do we know what the warrant stated? If it authorized them to take the rack containing the server they were after, then this is legal, if unfortunate.

If the police have a warrant for my apartment, and you happen to leave your backpack and server, your stuff will most likely be confiscated, along with mine, if it interests the police.

Re: The FBI stole an Instapaper server in an unrelated raid

#23

Post by tptacek » Thu, Jun 23, 2011, 5:42 PM UTC

mrcharles wrote: post #8

yuvadam wrote: post #6

I'm trying to think of an analogy which can explain why this might be reasonable from the FBIs perspective. Suppose you were using a shared storage space (shared servers, or server farm) with several other dudes. One of them is a drug dealer. One day the police/FBI decide to raid the storage space since the drug dealer has been using it to store illegal drugs. Is it not reasonable to consider this collateral damage (…

No. Even if it was shared space, it should be possible to, through software and IT, extract the necessary data and bar it from further operation.

I don't think the IT skill required to reliably extract evidence from an arbitrary hosting operation (of potentially arbitrary complexity) is simply "on tap" for the FBI.

If you want to say "tough luck that's just what it costs to collect evidence in 2011", fine, but it's probably not fair to say that the FBI should just naturally have that capability.

Re: The FBI stole an Instapaper server in an unrelated raid

#24

Post by pavel_lishin » Thu, Jun 23, 2011, 5:43 PM UTC

imrehg wrote: post #21

nbpoole wrote: post #4

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 (potentiall…

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?

Re: The FBI stole an Instapaper server in an unrelated raid

#25

Post by Xk » Thu, Jun 23, 2011, 5:44 PM UTC

Instapaper stores only salted SHA-1 hashes of passwords, so those are relatively safe.

--

Obligatory statement on NEVER USING SHA-1 HASHES to make passwords "safe".

Any normal person can brute force millions of SHA-1 hashes (salted however much you want) per second on a GPU.

If the FBI so wanted (although I don't believe they do) I'm sure they could brute force almost every single password in that database. Granted, it's the government and they have better ways of obtaining such information, but if there is someone the FBI is watching on Instapaper's databases and they so wanted, storing the SHA-1 hash of the password all but handed them over to the FBI.

I am now glad my Instapaper password was generated randomly, 16 characters long, and I will now change it just to be safe.

For anyone running a database which stores ussername/passwords, take a look at bcrypt or scrypt. They're millions (no, I am not exaggerating) of time better than SHA-1.

(Edit: Grammar)

Re: The FBI stole an Instapaper server in an unrelated raid

#26

Post by pavel_lishin » Thu, Jun 23, 2011, 5:44 PM UTC

leon_ wrote: post #20

Hmm. I've built something similar to instapaper for myself. (Using a native OS X app). People were making jokes at me how I was re-inventing the wheel. Now I'm somewhat happy having done the extra work. At least the FBI doesn't have my "read later" bookmarks. (Which often consist of the words 'hack', 'malware' and 'reverse engineering'.) I guess I will reinvent the wheel instead of using cloud services more often in…

An in between solution would be better - write an open source version of Instapaper that people could install on their own servers, instead of everyone rolling their own.

Re: The FBI stole an Instapaper server in an unrelated raid

#27

Post by pavel_lishin » Thu, Jun 23, 2011, 5:46 PM UTC

mrcharles wrote: post #2

All the more reason for data havens to exist. Run your server from a country where the police can't just take it with impunity.

Of course, then you have to keep careful tabs on that country's politics. The police can't confiscate your data in June, until a new bill is passed in July, and suddenly it's up for grabs.

Furthermore, I'm not sure I'd want to host my data in a country where the police cannot pursue digital criminals.

Re: The FBI stole an Instapaper server in an unrelated raid

#28

Post by tptacek » Thu, Jun 23, 2011, 5:47 PM UTC

[deleted] wrote: post #15

[deleted]

I didn't downvote you, but your "If you're the FBI and you want X, you'd simply Y" has nothing to do with reality. In reality, when any law enforcement organization needs digital evidence of any kind, they take everything. There are chain-of-custody rules that require it.

Re: The FBI stole an Instapaper server in an unrelated raid

#29

Post by pavel_lishin » Thu, Jun 23, 2011, 5:47 PM UTC

Astrohacker wrote: post #16

I think it may be prudent to begin encrypting all data on disk that can reasonably be encrypted while being able to set up the server remotely so that no one can just snatch your server and get all your data. This could work by encrypting your database in a truecrypt volume that must be mounted by entering the password. Thus, the data is only ever saved on disk in encrypted form, and the key to access the data is not…

How fast is Truecrypt? How much would this slow down database and file access?

Re: The FBI stole an Instapaper server in an unrelated raid

#30

Post by IgorPartola » Thu, Jun 23, 2011, 5:49 PM UTC

Xk wrote: post #25

Instapaper stores only salted SHA-1 hashes of passwords, so those are relatively safe. -- Obligatory statement on NEVER USING SHA-1 HASHES to make passwords "safe". Any normal person can brute force millions of SHA-1 hashes (salted however much you want) per second on a GPU. If the FBI so wanted (although I don't believe they do) I'm sure they could brute force almost every single password in that database. Granted,…

I have been thinking about switching everything to bcrypt, but there is definitely way too much confusion about bcrypt vs scrypt, how many rounds to set for bcrypt, etc. What is the definitive source for figuring out what the new standard should be? Does anyone have any links to something that's peer-reviewed and approved for use by someone with enough authority to do so?