The FBI stole an Instapaper server in an unrelated raid • Hacker News Board

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

#241

Post by eneveu » Fri, Jun 24, 2011, 9:56 AM UTC

tptacek wrote: post #41

IgorPartola wrote: post #30

Earlier quoted context omitted.

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?

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…

I got into a debate on StackOverflow over bcrypt vs salted SHA1:

http://stackoverflow.com/questions/3722780/do-any-security-e...

I think I'm right in choosing bcrypt, but one interesting argument against it was that, being slower, it would facilitate DoS attacks. You want the password hashing to be slow to prevent brute-forcing, but, if it's too slow, attackers could supposedly DoS your login system by trying tons of passwords.

I'm not a security expert, and I didn't know what to respond to that. How would one mitigate this problem? Is it even really a problem?

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

#242

Post by tankenmate » Fri, Jun 24, 2011, 10:37 AM UTC

dspace wrote: post #186

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

This is more "crypto nerd imagination", a la the XKCD comic. The FBI doesn't care about the encrypted passwords because it has access to all the content in plaintext. And what else would they need the passwords for? Other accounts on other services? They can just confiscate those servers too, where the content is most likely also in plaintext. So in this case , where the FBI is involve, using a SHA-1 hash poses no ex…

In this case since the warrant probably didn't allow for the seizure of Instapaper's servers / data you run a serious Fourth Amendment risk of any evidence within being inadmissible. That said even if it is inadmissible the FBI now know things they might not have known before. There is the obvious point that there is very little likelihood of any direct evidence of a crime in Instapaper's data, there maybe indirect or circumstantial evidence though.

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

#243

Post by marbletiles » Fri, Jun 24, 2011, 11:09 AM UTC

lwat wrote: post #212

marbletiles wrote: post #168

Earlier quoted context omitted.

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

Are you joking?

No, not at all. Until a few months ago, Instapaper didn't require users to set a password -- you could (and originally were encouraged to) use it without a password at all.

This makes a lot of sense. If more sites storing non-critical data did this we'd have far less password fatigue and people more wary about what they trust to such sites. Just now they see their "password1" as impenetrable security when they might as well have no password at all.

Not having a password has a similar psychological effect as showing the password field in plain text, I think.

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

#244

Post by dekz » Fri, Jun 24, 2011, 11:44 AM UTC

eneveu wrote: post #241

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…

I got into a debate on StackOverflow over bcrypt vs salted SHA1: http://stackoverflow.com/questions/3722780/do-any-security-e... I think I'm right in choosing bcrypt, but one interesting argument against it was that, being slower, it would facilitate DoS attacks. You want the password hashing to be slow to prevent brute-forcing, but, if it's too slow, attackers could supposedly DoS your login system by trying tons of…

One of the fundamental ideas of cryptology is using the right algorithm for the type of data and the length of its required security. If the cost required to break an algorithm is greater than the value of of the encrypted data, you're probably safe.

You can always store the password of the users again and update the crypto used, (more iterations, different digest algorithm). It's never a question of if it will be broken, but when.

Choosing iterations for a PBKDF takes a bit of common sense, yes if you're going to roflscale and think 100000000 iterations is a good idea currently, then you may run into performance issues.

The correct balance is performance vs security and you can only choose one. You want to authenticate the user as fast as possible while also making it unfeasible to recover the data. As with everything, a little common sense and knowledge goes a long way.

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

#245

Post by bad_user » Fri, Jun 24, 2011, 11:54 AM UTC

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…

If I get in your car that's just laying there on the street and "borrow" it for a week without telling you anything, do you think the court will question whether I overstepped my bounds? Do you think I can avoid getting slapped?

After all, I do have the right to drive cars, including cars which I don't own.

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

#246

Post by Joakal » Fri, Jun 24, 2011, 1:53 PM UTC

eneveu wrote: post #241

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…

I got into a debate on StackOverflow over bcrypt vs salted SHA1: http://stackoverflow.com/questions/3722780/do-any-security-e... I think I'm right in choosing bcrypt, but one interesting argument against it was that, being slower, it would facilitate DoS attacks. You want the password hashing to be slow to prevent brute-forcing, but, if it's too slow, attackers could supposedly DoS your login system by trying tons of…

Just like you don't want over 60 requests per second from a client, you don't want them to be able to allow that much log in attempts. Look at Gmail failed login process. A captcha is required after 3 failed attempts is preferable to a "you can't login after this many attempts" that I remember getting on a forum.

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

#247

Post by [deleted] » Fri, Jun 24, 2011, 1:57 PM UTC

danssig wrote: post #238

esrauch wrote: post #218

Earlier quoted context omitted.

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.

There are systems you can use to defeat this. One password decrypts the drive, another wipes it.

[deleted]

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

#248

Post by kijinbear » Fri, Jun 24, 2011, 2:07 PM UTC

esrauch wrote: post #218

kijinbear wrote: post #46

Earlier quoted context omitted.

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.

The company in question is actually located outside of the US, and so are all employees who have access to the key. It keeps its servers in the US only because of issues with cost and latency, I think.

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

#249

Post by delinka » Fri, Jun 24, 2011, 2:30 PM UTC

bad_user wrote: post #245

danielsoneg wrote: post #87

Earlier quoted context omitted.

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…

If I get in your car that's just laying there on the street and "borrow" it for a week without telling you anything, do you think the court will question whether I overstepped my bounds ? Do you think I can avoid getting slapped? After all, I do have the right to drive cars, including cars which I don't own.

What? No, seriously-- what?

How is this at all analogous to a warranted search? The FBI had permission to take something - so did they perform due diligence to make sure they took the correct something? That is the question.

So let's say I gave you permission to drive my car. It's green. You hop in a green car near my house, find the keys in the ignition and leave for four hours of errands. (Typically, I'd give you my key and you'd select a car that the key fits, but not today.) My neighbor reports his green car stolen and the police intercept you on your way back into the neighborhood. Did you perform "proper diligence" in selecting the correct car to take?

I have no idea how this situation would play out, but I suspect your own intent (to drive MY green car) plays into the considerations of the prosecuting attorney.

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

#250

Post by cheald » Fri, Jun 24, 2011, 2:52 PM UTC

GHFigs wrote: post #143

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…

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.

Can you elaborate on this? Are there setups where a single virtual machine spans multiple blades?