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

61–70 of 263 posts

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

#61

Post by ktsmith »

WettowelReactor wrote: post #40
falcolas wrote: post #11

Earlier quoted context omitted.

I think it's always important to remember that the first order of business in a raid is to preserve evidence against deletion or modification. This means that their first task is to remove the hardware from anybody's hands but theirs. At which point they can peruse the data as they are able. Why did they take an entire rack, instead of a few servers? I can think of a couple of potential reasons. - VM's, which could p…

No, the first order of business is to stay within the bounds of the law. It does not matter how solid your chain of evidence is if that evidence is illegally obtained.

It's doubtful the evidence was illegally obtained. The warrant was probably for the hardware, and was probably overly broad allowing for the removal of more than was necessary. That's been the routine since at least the mid 90s. There are plenty of cases where the FBI has walked into a data center shown a warrant and walked out with complete racks of equipment most unrelated to their actual search because the warrant allowed them to do so.

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

#63

Post by pavel_lishin »

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

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.

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

#64

Post by [deleted] »

WettowelReactor wrote: post #40
falcolas wrote: post #11

Earlier quoted context omitted.

I think it's always important to remember that the first order of business in a raid is to preserve evidence against deletion or modification. This means that their first task is to remove the hardware from anybody's hands but theirs. At which point they can peruse the data as they are able. Why did they take an entire rack, instead of a few servers? I can think of a couple of potential reasons. - VM's, which could p…

No, the first order of business is to stay within the bounds of the law. It does not matter how solid your chain of evidence is if that evidence is illegally obtained.

[deleted]

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

#65

Post by 5l »

pavel_lishin wrote: post #27
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.

Like it or not it's still the wild west, and I suspect most people here trust their own ability to protect themselves more than they trust the sheriff who only investigates crimes against the mayor and can't even ride a horse or shoot straight.

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

#66

Post by mbreese »

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,…

That was my first thought too. Not only does the FBI have the salted hashes, but they also have a copy of the code for the website. So they know what the salt values are. This makes it even easier to brute force the hashes.

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

#67

Post by mwytock »

getsat wrote: post #36
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,…

> can brute force millions Modern consumer video cards can do billions per second now. You might as well just store them in plaintext instead of using SHA1/MD5 with or without salting. :/

I dont understand. If you can use mixed-cased, letters and symbols you have 26 * 2 + 20 = 72 possible characters.

72^8 >> 1e9

It would still take more than 8 days to brute force at 1 billion/sec. And using a longer password (16 chars?) would make this a very long time.

Or is there other trick that makes this fast? Or, is it simply that people don't choose random, long passwords?

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

#68

Post by IgorPartola »

tptacek wrote: post #41
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?

No there isn't. You only think that because when geeks discuss anything that involves one or more knobs, a huge debate must necessarily ensue about the proper values of those knobs. Just use the bcrypt defaults. You will be fine. You will in particular be so much better off than salted SHA-1 that this topic will be mooted. Later on, maybe in 5-10 years, you can re-engage with the debate about what a good cost factor…

Thanks. I am just trying to navigate the sea of misinformation that spews forth everywhere about salted hashes vs bcrypt vs scrypt. I can see that lots of people claim that bcrypt is better, but I am not aware of anything about it other than the original paper. Basically, I want to know what the chances are that two months after I implement bcrypt a huge issue with it will be discovered and I'll have to move everything to some new scheme.

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

#69

Post by tptacek »

mwytock wrote: post #67
getsat wrote: post #36

Earlier quoted context omitted.

> can brute force millions Modern consumer video cards can do billions per second now. You might as well just store them in plaintext instead of using SHA1/MD5 with or without salting. :/

I dont understand. If you can use mixed-cased, letters and symbols you have 26 * 2 + 20 = 72 possible characters. 72^8 >> 1e9 It would still take more than 8 days to brute force at 1 billion/sec. And using a longer password (16 chars?) would make this a very long time. Or is there other trick that makes this fast? Or, is it simply that people don't choose random, long passwords?

Secure password hashes don't protect users, and particularly not users who use one-time effectively-random passwords.

Secure password hashes protect application developers from the disclosure of hundreds or thousands of user passwords from their database. It allows them to attest to their userbase "your password is cryptographically stored in a manner that makes them hard to break even by dedicated hardware; you should consider changing your password if it's weak and shared", instead of, "expect to see your password on Pastebin any day now".

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

#70

Post by cheez »

tptacek wrote: post #44
cheez wrote: post #31

Earlier quoted context omitted.

Can you describe why it's better?

http://codahale.com/how-to-safely-store-a-password/ (Be prepared for your comment score to visit the grey depths if you attempt to relitigate Coda's blog post here and don't know exactly what you're talking about.)

That might be the most awesome page I've ever read.

Bcrypt it is :-)

Post reply on HN