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

141–150 of 263 posts

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

#141

Post by tptacek »

encoderer wrote: post #133
tptacek wrote: post #72

Earlier quoted context omitted.

You've been downmodded because password hash salts are public nonce values; usually, schemes that depend on "secret salts" are crackpot alternatives to secure password hashes. (I didn't downmod you).

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…

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.

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

#142

Post by zoul »

encoderer wrote: post #133
tptacek wrote: post #72

Earlier quoted context omitted.

You've been downmodded because password hash salts are public nonce values; usually, schemes that depend on "secret salts" are crackpot alternatives to secure password hashes. (I didn't downmod you).

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…

I might have read your question wrong, but the whole point of this thread is that passwords stored by hashing with a general purpose hashing algorithm can be easily brute-forced nowadays. Salting just turns your password into a different string and has no substantial effect on the brute force attack. (The attacker is already trying all possible strings.)

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

#143

Post by GHFigs »

cheald wrote: post #13
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 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…

If he was sharing a physical machine with the bad guys, then yeah, sorry, that's collateral damage. However, if he was on his own separate leased machine, there is absolutely no reason for the FBI to seize it.

The problem is that with blade servers like DigitalOne provided, both of these things can be true at the same time.

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

#145

Post by lamnk »

bestes wrote: post #17

I think the OP was unreasonably harsh on DigitalOne (never heard of them let alone have any interests). It is very possible that they are consumed with FBI questioning, gag orders or who knows what else. I would give them a pass for a few days until more detail comes out.

I think so too. He says:

   I have no idea whether I’ll ever see the server again
In this case the host probably doesn't know better than him. According to the NYTimes they are a swiss company, they only rent space and connectivity from the data center.

I see people jump up and down accusing their host being a bad host when their websites go down for 10 minutes. The thing is, shit like this happens all the time. Some years ago even Rackspace was taken offline because a truck hit their data center. Bizarre, right? Yes, but it did happen.

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

#146

Post by oskarkv »

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'm just wondering: What if I used SHA-1 a million times on the password, i.e. hashing the hash over and over. Wouldn't that make it much more time-consuming for an attacker? Or am I missing something? The input every time but the first would be a random-looking 160 bit number, so it would be hard to guess. And if the attacker wanna look for common passwords in a dictionary the attacker must hash them a million times, no?

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

#147

Post by rubinelli »

encoderer wrote: post #133
tptacek wrote: post #72

Earlier quoted context omitted.

You've been downmodded because password hash salts are public nonce values; usually, schemes that depend on "secret salts" are crackpot alternatives to secure password hashes. (I didn't downmod you).

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.

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

#148

Post by encoderer »

tptacek wrote: post #141
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…

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?

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

#149

Post by encoderer »

Xk wrote: post #134
encoderer wrote: post #129

Earlier quoted context omitted.

Woah, slow down, I think you whipped up a 4 paragraph reply before you ever got to my last sentence. Or, go on and tell me more about all the things hashes are used for as if I just fell off the turnip truck. This discussion is not about checksums on files. It's abotu passwords. And your "perfect hash" in your example about passwords is "freakishly fast." In fact, like the other guy that replied to me mentioned, this…

When you wrote "this fictional hash" I read that as talking about the SHA-4 I made up, not the one you did. I then didn't respond to the rest of the post because when you said "for password hashing, it's a good start" I again assumed you were talking about my hash function, which is not good for hashing. Yours would be perfectly fine. I apologize.

Apology accepted, and thank you for adding a lot to the discussion further down the page (the interesting maths related to the probability of collisions on a hashed-hash)

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

#150

Post by jonah »

forgotAgain wrote: post #131
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?

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.
Post reply on HN