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

101–110 of 263 posts

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

#101

Post by nkassis »

PatrickTulskie wrote: post #12
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 seems like either the FBI didn't pay attention to the information given to them by DigitalOne or DigitalOne had poor information about where their servers are located. The picture painted here is that the FBI came in and hastily took a bunch of equipment without making sure they were taking the right stuff. If that is accurate, then it's likely they might have missed a server with data on it that they needed for t…

I was under the impression that DigitalOne wasn't even informed (they were in sweden or something) until 3 hours after the incident (from the NYT article).

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

#102

Post by Xk »

StavrosK wrote: post #95
Xk wrote: post #91

Earlier quoted context omitted.

You have two choices that I see: 1. The next time a user logs in to your system and you verify against the SHA-1 hash that they are who they say they are, recompute the correct hash for bcrypt. Then, delete the SHA-1 hash . It does you no good to have a bcrypt version if you keep the SHA-1 version around. 2. Generate the bcrypt hash from the SHA-1 hash. That is, pretend that the SHA-1 hash is the user's password. Thi…

Or you can do both, migrate everything to bcrypted SHA for now and then replace these with straight up bcrypt the next time the user logs in. You ostensibly have a hash method identifier per hash, so just create "sha+bc" and "bc" along with your current "sha". Also, why is the risk of a collision greater? It seems to me that, if anything, it should be lower, as SHA hashes always consist of a fixed number of bits, and…

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(Q)). We first have the chance of 1 in 2^128 that F(P) == F(Q) which implies G(F(P)) == G(F(Q)). However, that is not all!

We now have a new 1 in 2^128 chance that G(F(P)) == G(F(Q)). So we have (about) a 1 in 2^127 chance that the passwords will collide.

But, none of this really matters. Collisions aren't what you worry about with password hashes.

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

#103

Post by boucher »

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…

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.

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

#104

Post by tptacek »

StavrosK wrote: post #94
tptacek wrote: post #60

Earlier quoted context omitted.

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 .

> Salted hashes are a straight-up vulnerability. I find this a bit of a misnomer. I understand what you mean in context, of course, but, strictly speaking, bcrypt is a "hash", and "salted" is always good.

What was your goal with this comment?

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

#105

Post by tptacek »

rchowe wrote: post #99
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.]

But there are rainbow tables, or tables of all of the MD5s/SHA1s/ for arbitrary strings. So the time's already sunk in. 8 days for one password is a very short amount of time comparatively (tiny for a botnet). If you use bcrypt, which you can force a certain complexity on, you can get that amount of time up much higher.

Rainbow tables don't work even against amateurish salted hash schemes.

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

#106

Post by brown9-2 »

pavel_lishin wrote: post #22
cheald wrote: post #13

Earlier quoted context omitted.

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.

No, this does not seem to be public knowledge. For all we know the Instapaper (and pinboard, etc) servers could have been included in the warrant.

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

#107

Post by StavrosK »

Xk wrote: post #102
StavrosK wrote: post #95

Earlier quoted context omitted.

Or you can do both, migrate everything to bcrypted SHA for now and then replace these with straight up bcrypt the next time the user logs in. You ostensibly have a hash method identifier per hash, so just create "sha+bc" and "bc" along with your current "sha". Also, why is the risk of a collision greater? It seems to me that, if anything, it should be lower, as SHA hashes always consist of a fixed number of bits, and…

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 different SHA hashes (ones that haven't already collided), the probability that bcrypt will collide might be smaller (or zero, as in my example above).

In reality it doesn't work like that, I know, but in theory you can't be sure that the probabilities of collision will add (or, well, multiply) up.

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

#108

Post by StavrosK »

tptacek wrote: post #104
StavrosK wrote: post #94

Earlier quoted context omitted.

> Salted hashes are a straight-up vulnerability. I find this a bit of a misnomer. I understand what you mean in context, of course, but, strictly speaking, bcrypt is a "hash", and "salted" is always good.

What was your goal with this comment?

Clarification. Right now we have

> Salted hashes are a straight-up vulnerability. -- tptacek

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

#109

Post by Xk »

Hawramani wrote: post #93
mwytock wrote: post #67

Earlier quoted context omitted.

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?

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 SHA-4 function is perfect in every way, it would be strictly worse to use this for password hashing than SHA-1. Why? Because cryptographic attacks aren't the problem here. The problem is that the entropy of a user's password is very VERY small. So small, in fact, that attacks on passwords aren't done through cryptographic weaknesses, they are done by simply hashing everything someone might pick as a password and asking "did I get it right?". An attacker will repeat this process for a little while, and eventually they'll get the answer "YES, this user chose to make abc123 as their password!".

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

#110

Post by WettowelReactor »

ktsmith wrote: post #61
WettowelReactor wrote: post #40

Earlier quoted context omitted.

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…

If the warrant allows them to do so then yes it is legal although we should hold judges accountable. Voting in responsible judges is more important than legislatures IMHO as they tend to have a more direct impact on our personal lives. That being said I just see a lot of comments mentioning the imperative to preserve evidence and chain of custody which is important but completely subordinate to staying within the bounds of the warrant. Does anyone here know if warrants can be obtained through FOIA requests? I would sure love to see the scope of the one used in this case.
Post reply on HN