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

211–220 of 263 posts

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

#211

Post by sliverstorm »

sunchild wrote: post #199
kragen wrote: post #176

Earlier quoted context omitted.

To clarify, I assume you mean that using secure password hashes instead of insecure ones does not help users who use one-time effectively-random passwords, because those users are already safe? That is true. However, it seems to me that the combination of an effectively-random password and password hashing does protect users, because their password is not effectively crackable in a situation like this. Additionally,…

I wish everyone could use complex, unique, strong passwords all the time, but some use cases just don't support it. For example, I have to type my Apple ID into my iPhone/iPad what seems like every 5 minutes in iOS. Without access to 1password or a similar tool, I just can't use a strong password. Even if I did, I couldn't change it as often as I'd like to. FWIW, I wish I could.

security vs. convenience

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

#212

Post by lwat »

marbletiles wrote: post #168
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,…

Was far happier when he didn't store passwords at all, tbh.

Are you joking?

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

#214

Post by caf »

derrickpetzold wrote: post #206
caf wrote: post #203

Earlier quoted context omitted.

While it is certainly a good idea, as a user, to assume that the site developers have done things wrong (and therefore choose a strong, random, unique password), it is also a good idea, as a site developer, to assume that your users are doing things wrong (and therefore choose a strong password hashing method).

Security through obscurity is never a good idea because it leaves a false sense of security. I know I am getting totally destroyed here by the down voting and I'll probably end up in negative karma for this but I standby all of it.

I am not advocating security through obscurity.

I am saying that your advice is appropriate for users (who cannot control what the server does) but inappropriate for servers (who cannot control what the user does).

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

#215

Post by rdl »

JonnieCache wrote: post #210
rdl wrote: post #191

Earlier quoted context omitted.

Absolutely. That's essentially PBKDF2 ( http://en.wikipedia.org/wiki/PBKDF2 ). You usually add a salt (an additional string which is stored in the clear, but which makes your local instance globally unique, so the attacker can't precompute value to hash mappings ("Rainbow Tables" [which are faster to make if you have alien technology, from what I've heard]) for all sites. I'd still suggest using bcrypt or scrypt.

Bcrypt typically generates and stores the salt with the rest of the hash, all on its own, which reduces the chance for developer error. It's idiot-proof basically.

Of course, the other key thing is to avoid giving attackers offline access to the hash database if possible. Even with scrypt, if you let someone try offline, he will get good results on 100 password attempts per account. Users are often using such weak passwords that being only an online oracle and able to shut down after a number of tries on a password, or at least to do app level rate limiting, is still useful.

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

#216

Post by xuki »

notatoad wrote: post #136
xuki wrote: post #75

Earlier quoted context omitted.

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.

No it does not. I once lived in a house and the owner went bankrupt, they (the bank) seized the house immediately. How is that even possible if the house was mine that very moment?

I agree that the information belonged to Instapaper.

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

#217

Post by epoxyhockey »

maw wrote: post #180
johngalt wrote: post #132

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…

Good question. No solid answers here, but my guess would be some combination of more redundancy, better and more active lawyers, and the large players not talking about it when it does go down.

FB, Google, etc all provide a nice procedure for LEO to query all desired info. It is not necessary to seize equipment. Example: https://www.eff.org/files/filenode/social_network/Facebook20... (pdf)

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

#218

Post by esrauch »

kijinbear wrote: post #46
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?

Full-disk encryption. You enter the key whenever the system needs to be rebooted. I know at least one company that does this with all of their US-hosted servers.

This would only be protection against thieves that steal your harddrives, if the US government had your drives they can legally compel you to divulge your password.

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

#219

Post by gwright »

m0nastic wrote: post #193
gwright wrote: post #188

Earlier quoted context omitted.

Consider an analogy. The FBI gets a valid warrant for the servers belonging to a company with a street address of "101 Main St, Somewhere, DC". The building at 101 Main St. is a multi-tenant, multi-story, office building. If the FBI seized all the computer equipment in the entire building or even just the computers on the same floor as the targeted company but belonging to other companies who just happen to be physic…

I don't think that would be reasonable, but I also don't think that is analagous. For starters, that hypothetical search warrant is too broad to be executed. Keep in mind, I'm not saying that I believe that the FBI executed this seizure correctly. I'm saying that based on third-hand limited information, I don't think it's possible to rule out the possibility that what they did was warranted. If you showed up to perfo…

But you've simply pointed out the strength of the analogy. Siezing adjacent blades in a multi-tenant rack is just as nonsensical as siezing adjacent computers in a multi-tenant office.

Physical proximity is simply not a valid justification in either situation.

If the courts and/or the FBI are unable to understand this, the remedy is to get them educated and not to simply accept the consequences of overly-broad warrants or seizures.

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

#220

Post by foobarbazetc »

Astrohacker wrote: post #16

I think it may be prudent to begin encrypting all data on disk that can reasonably be encrypted while being able to set up the server remotely so that no one can just snatch your server and get all your data. This could work by encrypting your database in a truecrypt volume that must be mounted by entering the password. Thus, the data is only ever saved on disk in encrypted form, and the key to access the data is not…

Yeah, and watch your database IOPs fall by 1000x.

It's not feasible to run databases on encrypted block devices. Some databases let you encrypt certain tables or columns, though.

Post reply on HN