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

151–160 of 263 posts

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

#151

Post by roc »

gokhan wrote: post #140

What's the proper way of storing OAuth tokens in this situation? Given that all the tokens of users and your private key is on the server (even if it's embedded in code), there's no way for Instapaper for keeping those tokens secure in case of a compromise (by FBI or Lulzdudes or anyone). Seems like Instapaper should change it's private key for, say, Facebook.

I would think encrypting the third-party tokens with the user's password would be a decent start.

When the user's password is verified, it could be used to unlock those tokens and store them in the active session structure in RAM. There'd still be some exposure, particularly in the case of being rooted, but an attacker couldn't just dump the database.

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

#152

Post by ChuckMcM »

It would make for an interesting Freedom of Information (equipment) request. "Give me my damn server back." But the damage is of course done.

If you are a voting citizen of the US I recommend you write (not email, write a letter, put postage on it and everything) to your elected congressional representatives and ask that Congress immediately put curbs on the police powers of the FBI when it comes to infrastructure seizures.

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

#153

Post by encoderer »

rubinelli wrote: post #147
encoderer wrote: post #133

Earlier quoted context omitted.

thomas, another programmer in the office just asked this question which I haven't a good answer for: Instead of using a known salt stored in, say, a config file, or prepended to the stored hash, why not derive the salt from some substr of the supplied password? His example was, salt would be concat(left3chars, right3chars). And so when the user inputs his password into the system, you just derive the salt using that…

Generating the salt from the password completely defeats its purpose. Users with the same password will have the same salt, and therefore the same hash. In your example, an attacker could find which users chose the password "password" by running your hashing algorithm with a salt value of "pasord". Your database would be wide open to rainbow table attacks.

Right, so then the idea is that if they get your DB dumb, and see this salt scheme in your code, they can compute a rainbow table using it and now they have cracked all your passwords in the time it would take to brute force one (well, not really, because it's not as if they'd have to brute force the entire keyspace before they got to the one password they're trying to break, but I think I'm onto the right idea about shrinking down the magnitude of the problem)

But what it WOULD do -- which is what to be honest tricked me about the concept -- is that it would still offer protection from a precomputed rainbow table that knew nothing of your sheme to derive salt from the password. (eg, the rainbow tables that are publicly searchable right now)

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

#155

Post by [deleted] »

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?

[deleted]

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

#156

Post by tptacek »

encoderer wrote: post #148
tptacek wrote: post #141

Earlier quoted context omitted.

The purpose of a salt is to randomize the password hashes so you can't easily precompute them. A "salt" derived from the password itself isn't random; it's deterministic. Salts don't add much security, but they do defeat precomputation. The scheme your coworker proposed doesn't do that.

I'm not going to lie and say I was already thinking that, but I did have a notion that, in such a scheme, if somebodies passowrd was "1111111" then your salt + password would be the unimpressive 1111111111111. But if you don't mind a follow-up, wouldn't it still defeat rainbow tables? Why not?

In your scheme, if your password is "apple scrapple", the hash value is always going to be (say) "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15". An attacker can precompute that and just use text search to find everyone with the password "apple scrapple".

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

#157

Post by danielsoneg »

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?

>You could always hash the e-mails, although this would make resetting your password impossible.

Not really - everywhere I've gone has asked me for my email to send me my password. Same principle as with passwords: enter your email, we hash it, if it matches a hashed email in the DB, we send a 'reset' email to the address you entered.

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

#158

Post by ahi »

getsat wrote: post #81
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?

You're looking at more like 5+ billion/sec today. There was a listing of modern consumer video cards + their hashing capabilities posted on another HN story recently, but I can't find it.

https://en.bitcoin.it/wiki/Mining_hardware_comparison

Not sure if this is what you were looking for or the particular hash bitcoin uses, but a $110 Radeon 5830 can get you around 250Mhash/s

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

#159

Post by gte910h »

danielsoneg wrote: post #87
cheez wrote: post #33

Earlier quoted context omitted.

It's called the constitution of the United States. If the enforcers don't follow it, your only recourse is the Supreme Court which will probably throw out your claim for national security reasons.

Not necessarily. I (also) am not a lawyer, but the question isn't whether the FBI has the authority, constitutional or otherwise, to seize the servers owned by the target of the warrant, the question is whether they overstepped their bounds in seizing three whole racks of servers. If it's shown they were careless or did not take sufficient caution in their raid to avoid seizing unrelated servers, they could be held l…

It is a 4th amendment issue: That's why they can't just take the server of people not under investigation...

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

#160

Post by forgotAgain »

jonah wrote: post #150
forgotAgain wrote: post #131

Earlier quoted context omitted.

If the hardware is in hand then I don't see any practical way to protect the information. The only way that works is to not store the information in cloud servers.

The only way that works is to not store the information in cloud servers. Where would your servers be safe? Colo? No. In your basement? No? In another country? Possibly, depends. At HavenCo? Maybe.

I was talking from a user's perspective. As a user your data is safer on your local machine than on a cloud server run by who knows who.
Post reply on HN