Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The FBI stole an Instapaper server in an unrelated raid

blog.instapaper.com

Post reply on HN
Print view View original

51–60 of 263 posts

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

#51

Post by rosser »

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?

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.

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

#52

Post by seiji »

IgorPartola wrote: post #30
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?

scrypt slides: http://www.tarsnap.com/scrypt/scrypt-slides.pdf

Takeaway: Cost to crack one MD5 password: $1. Cost to crack one scrypt password: $50M to $200B.

You want your login to be slow compared to the rest of your application. It's okay to take half a second to verify a login.

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

#53

Post by andrewcooke »

cheez wrote: post #38
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…

I don't think this is reasonable. If you lose power, the the volume is toast as I understand it.

if i'm understanding you correctly, you're wrong. it's just another layer in the system (one more function in the mapping from your data to magnetic patterns - a function that's completely reasonable, predictable, etc, just hard to guess). the problem is that you need to enter the password on boot, which makes automated startup difficult.

for example, my laptop disk's main partition is encrypted. i need to enter the password when i boot, but nothing terrible happens if i lose power or the system crashes or whatever.

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

#54

Post by [deleted] »

tptacek wrote: post #28
[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.

[deleted]

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

#55

Post by tptacek »

mrcharles wrote: post #39
tptacek wrote: post #23

Earlier quoted context omitted.

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.

Yeah well, actions like this give the image of fat guys in suits who hunt and peck at the keyboard and move icons around on the desktop to find where they are hiding that dang data.

Should they get better forensics people? Absolutely.

But, steel yourself: a very good forensics pro would probably have them acquiring expansive warrants for hardware seizures, because very good forensics pros are paid to foresee all the crazy things colluding providers and criminals can do to hide evidence.

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

#58

Post by andrewcooke »

is there a better solution that encrypting data and putting the password in the source? obviously this is for cases where you can't use a hash.

it seems to me that, at least, it would make sense to have the db and web server physically separate in that case (although i guess someone stealing hardware is not normally a common scenario).

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

#59

Post by pbh »

discover wrote: post #49
pavel_lishin wrote: post #24

Earlier quoted context omitted.

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/

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

#60

Post by tptacek »

seiji wrote: post #52
IgorPartola wrote: post #30

Earlier quoted context omitted.

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?

scrypt slides: http://www.tarsnap.com/scrypt/scrypt-slides.pdf Takeaway: Cost to crack one MD5 password: $1. Cost to crack one scrypt password: $50M to $200B. You want your login to be slow compared to the rest of your application. It's okay to take half a second to verify a login.

scrypt is better than bcrypt, but not by the same margin that bcrypt is better than salted hashes. Salted hashes are a straight-up vulnerability. bcrypt is a best practice.

Note that almost nobody uses scrypt. We don't recommend it, not because it's insecure, but because it's painful to implement for most companies.

But use either. Or just use PBKDF2. All of the adaptive hashes are fine.

Post reply on HN