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

131–140 of 263 posts

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

#131

Post by forgotAgain »

imrehg wrote: post #21
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…

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.

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

#132

Post by johngalt »

Why isn't Facebook having their servers seized? Google? Amazon? If the FBI is really targeting the "badguys" I'm sure there have been more badguys using facebook/gmail/AWS than any single colo.

Why haven't there been similar seizures of any larger corporate entities? Even if the current FBI practices are valid, should the application of those practices be a function of size/wealth/power? Which servers of Sony's were seized after distributing rootkits?

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

#133

Post by encoderer »

tptacek wrote: post #72
mbreese wrote: post #66

Earlier quoted context omitted.

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.

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 same consistent algorithm, and supply both that derived salt and the password into the algorithm.

My only answer was "It's always a bad thing to be clever with crypto, just do it by the book" but he asked for more and I couldn't give him a sound debunking (or an authoritative endorsement).

I build systems -- and do it very well -- and all I know about crypto is what I've had to learn to implement other peoples crypto systems.

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

#134

Post by Xk »

encoderer wrote: post #129
Xk wrote: post #119

Earlier quoted context omitted.

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

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.

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

#136

Post by notatoad »

xuki wrote: post #75
notatoad wrote: post #35

Earlier quoted context omitted.

this is not shared hosting. the server taken belonged to instapaper. being located in the same datacenter should not be grounds for seizure. if you're looking for a metaphor, think about a self-storage facility ([one of these places]( http://www.moversandpackers.org/wp-content/uploads/2010/10/s... ). imagine you're renting one of those units, and somebody renting a unit on the other side of the yard is a drug dealer.…

The server belonged to Digital One. I didn’t own the hardware — I was leasing it from DigitalOne.

it belonged to instapaper. that's what leased means. if you lease a car or house or server or anything else, it belongs to you for the duration of the lease. and more importantly than the hardware, all the information on the server belonged to instapaper.

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

#137

Post by [deleted] »

tptacek wrote: post #92
thaumaturgy wrote: post #84

Earlier quoted context omitted.

In the defense of geeks, this probably follows from the mantra that you should never ever run any command on your system ever without completely and fully understanding what it does and all of its options and etc. etc. So now people are twitchy about "just use the defaults", especially when it comes to something they don't really understand, like cryptography.

As a geek let me just say that it is all love with me and the geeks. Just: in this case, you can just take the defaults and be better off.

[deleted]

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

#139

Post by pdebruic »

JabavuAdams wrote: post #74
tptacek wrote: post #41

Earlier quoted context omitted.

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…

What's a ready to go bcrypt library for C/C++? I mean include headers, link lib / so, and call a function. I've been looking into this over the past few days, and I've decided to just extract the relevant files from py-bcrypt, and get rid of the compatibility layer.

The C reference implementation is here:

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/

Its from OpenBSD and implemented by the developers of the algorithm. It is what the Python/Ruby/Lisp/PHP etc. versions are derived from or wrap

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

#140

Post by gokhan »

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.

Post reply on HN