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

111–120 of 263 posts

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

#111

Post by Xk »

StavrosK wrote: post #107
Xk wrote: post #102

Earlier quoted context omitted.

Imagine you have two hash functions F and G, both mapping from the domain of integers to integers mod 2^128. Imagine they are perfect in that if you hash all the integers up to some large N, each hash is expected to recorded exactly the same number of times (probabilistically). Now clearly if I hash a password F(P) and another password F(Q) there is a 1 in 2^128 chance they collide. Now imagine we do G(F(P)) and G(F(…

I see what you mean, and I agree that it doesn't matter, but it's an interesting exercise anyway. I disagree that there's a 2^128 chance that they will collide. Trivially, I can show you a hash that will never collide for up to some N, and that is F(P) = P mod 2^128. This will never collide unless P is more than 128 bits long. My rationale, above, was that SHA constrains the space to 128 bits. Therefore, for differen…

Point taken, it's probably true that the probability that G(F(P)) == G(F(Q)) given F(P) != F(Q) is less than 1 in 2^128. But it's probably also true that it's greater than 0.

Clearly it's impossible to be less than zero. So no matter what you do, Defining H(X) to be G(F(X)) will have strictly more collisions than F(X).

The reason I would argue it's greater than zero is that if a function H existed such that H(X) will never collide for X less than 2^128, it would probably have some cryptographic weakness.

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

#112

Post by StavrosK »

Xk wrote: post #111
StavrosK wrote: post #107

Earlier quoted context omitted.

I see what you mean, and I agree that it doesn't matter, but it's an interesting exercise anyway. I disagree that there's a 2^128 chance that they will collide. Trivially, I can show you a hash that will never collide for up to some N, and that is F(P) = P mod 2^128. This will never collide unless P is more than 128 bits long. My rationale, above, was that SHA constrains the space to 128 bits. Therefore, for differen…

Point taken, it's probably true that the probability that G(F(P)) == G(F(Q)) given F(P) != F(Q) is less than 1 in 2^128. But it's probably also true that it's greater than 0. Clearly it's impossible to be less than zero. So no matter what you do, Defining H(X) to be G(F(X)) will have strictly more collisions than F(X). The reason I would argue it's greater than zero is that if a function H existed such that H(X) will…

Hmm, you're right indeed, since they're additive. I should have said that the second layer is less likely to collide than the first, not than both combined.

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

#113

Post by encoderer »

Xk wrote: post #109
Hawramani wrote: post #93

Earlier quoted context omitted.

If my understanding is correct that's not the issue here. Hashes are meant to be one-way functions, the developer can easily check if a user's password matches the hash, but it should be practically impossible to deduce the password from the hash. What the user chose as their password should be irrelevant if using a good hash. [Edit: I stand corrected on the effect of password length.]

SHA-1 is a reasonably good hashing algorithm, but for the sake of argument, I'll talk about an imaginary SHA-4 which is perfect in every respect. It will be a 4096 bit hash function which has no faster-than-bruteforce collisions or preimage attacks or second preimage attacks. Let's also assume that this perfect SHA-4 function is freakishly fast, say, a million times faster than SHA-1. Now, even though my imaginary SH…

Right, which is the reason why "perfect in every respect" and "freakishly fast" are mutually exclusive in a hashing algorithm.

A "perfect in every respect" hash then would be one that takes a consistent, acceptably-long time. Some large fraction of a second perhaps.

Of course, this fictional hash wouldn't be the right choice for everything. But for password hashing, it's a good start.

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

#114

Post by JoachimSchipper »

StavrosK wrote: post #108
tptacek wrote: post #104

Earlier quoted context omitted.

What was your goal with this comment?

Clarification. Right now we have > Salted hashes are a straight-up vulnerability. -- tptacek

"Salted or unsalted versions of common hash functions (MD5, SHA-1, SHA-2, SHA-3) are not to be used to store passwords."

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

#115

Post by m0nastic »

tptacek wrote: post #23
mrcharles wrote: post #8

Earlier quoted context omitted.

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.

In general the FBI is still operating in a pre-datacenter mindset when it comes to evidence acquisition.

It wasn't until 2007 that they updated the Handbook of Forensic Services[1] to no longer require seizing peripherals of suspected evidence. Think about that for a second, that means mice, keyboards, monitors, etc.

The team who worked on this raid ironically is part of the DOD CCC, which is a joint forensic lab setup between the DOD and the FBI (they have two labs, one in Maryland, who would have been involved in this raid, and one in California). That team certainly has some smart folks on it (they're the subject-matter-experts for forensic acquisition at the FBI), but if they've devised special procedures for dealing with datacenter or cloud forensics, they haven't been codified yet into the HFS.

[1] http://www2.fbi.gov/hq/lab/handbook/forensics.pdf

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

#116

Post by pavel_lishin »

pbh wrote: post #59
discover wrote: post #49

Earlier quoted context omitted.

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.

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

#117

Post by ynniv »

pavel_lishin wrote: post #24
imrehg wrote: post #21

Earlier quoted context omitted.

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?

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.

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

#118

Post by smackfu »

To be clear, the server stopped responding, and the host he is paying for the server has not responded at all. The server could simply be unplugged, or all the network cables were unplugged during the raid. Who knows? I guess "The FBI stole my server is a better headline" though.

In my experience with our leased data center cages, we are expected to fly in to town if we ever need to physically manipulate the servers or even plug things in. The data center employees don't even go into the locked cages.

If the FBI forced open a locked cage, and did stuff in there, I would not expect anything to be addressed until DigitalOne showed up to fix it.

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

#119

Post by Xk »

encoderer wrote: post #113
Xk wrote: post #109

Earlier quoted context omitted.

SHA-1 is a reasonably good hashing algorithm, but for the sake of argument, I'll talk about an imaginary SHA-4 which is perfect in every respect. It will be a 4096 bit hash function which has no faster-than-bruteforce collisions or preimage attacks or second preimage attacks. Let's also assume that this perfect SHA-4 function is freakishly fast, say, a million times faster than SHA-1. Now, even though my imaginary SH…

Right, which is the reason why "perfect in every respect" and "freakishly fast" are mutually exclusive in a hashing algorithm. A "perfect in every respect" hash then would be one that takes a consistent, acceptably-long time. Some large fraction of a second perhaps. Of course, this fictional hash wouldn't be the right choice for everything. But for password hashing, it's a good start.

(Edit: see child comment -- I was responding to something other than what was intended. I'm leaving this here for clarity, but you can ignore it.)

No, not really. Hashing functions aren't designed for passwords, they're mainly used for integrity checks and other uses which need to be fast: why do you think one of the axes the SHA-3 hashes are competing on is speed?

You have your 10gb file and want to send it to your coworker and let him know it's really yours and no one has messed with it. So you run an HMAC over it and then sign it with your private key.

You want it to be as fast as possible. It would be optimal if there was a single x86 instruction called sha4 which did this in the time it takes to do an add.

Hashing is really, really not meant for passwords.

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

#120

Post by jonknee »

encoderer wrote: post #113
Xk wrote: post #109

Earlier quoted context omitted.

SHA-1 is a reasonably good hashing algorithm, but for the sake of argument, I'll talk about an imaginary SHA-4 which is perfect in every respect. It will be a 4096 bit hash function which has no faster-than-bruteforce collisions or preimage attacks or second preimage attacks. Let's also assume that this perfect SHA-4 function is freakishly fast, say, a million times faster than SHA-1. Now, even though my imaginary SH…

Right, which is the reason why "perfect in every respect" and "freakishly fast" are mutually exclusive in a hashing algorithm. A "perfect in every respect" hash then would be one that takes a consistent, acceptably-long time. Some large fraction of a second perhaps. Of course, this fictional hash wouldn't be the right choice for everything. But for password hashing, it's a good start.

... Which is pretty much what bcrypt is.

http://codahale.com/how-to-safely-store-a-password/

Post reply on HN