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

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

#171

Post by Xk » Thu, Jun 23, 2011, 9:36 PM UTC

derrickpetzold wrote: post #169

Xk wrote: post #166

Earlier quoted context omitted.

... what? > Just store in plaintext because I am already assuming you are. No, actually, I don't think I will store plaintext passwords. > All the this talk about sha-1 vs bcrpyt vs scrpyt is nice and all but I have little faith that most companies care about this as much as HN does. So what? Just because other people don't do it doesn't mean you don't have to also. Fortunately for us, there are a lot of startup foun…

> So what? Just because other people don't do it doesn't mean you don't have to also. Fortunately for us, there are a lot of startup founders here who might read this and learn something. Yes I hope there are. > I disagree. I think most people use SHA-1 because they know better than to store plaintext passwords. What they don't know is that it's terribly broken. SHA-1 is the default on django and its easy to break th…

> The real solution is site security not password security.

That does not imply you don't worry about it though -- it's defense in depth. In the same way sometimes you'll need to go through two sets of doors locked with different keys to access a secured server room (or anything else, for that matter), it's worthwhile to protect everything you can as best you can.

> They might as well be using ROT-13 if they are using any of those. Now with todays GPUs and rainbow tables the passwords might as well be in plaintext. The real solution is site security not password security.

Exactly my point. That's why you use bcrypt.

> For how long? 4-5 years? Who will be maintaining your site then?

First, the premise of that question is that bcrypt is going to be secure for only 4-5 years, which is entirely wrong. You can modify the work factor on bcrypt as time goes by. I could, for example, make it take twice as long to generate a hash every year. I could have the program do this automatically. As for you actual question, which isn't terribly relevant, either (1) me or (2) the next guy, who I hope will have knowledge about security as well, but if he doesn't, then I just have to hope he'd keep the workfactor increases in the code.

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

#172

Post by kindly » Thu, Jun 23, 2011, 9:37 PM UTC

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 currently use a sha hash (with salt) but rehash it x amounts of times. I have changed x over the years to be larger to get an acceptable trade off in computation time. Why is bcrypt much better than this? Is it because the algorithm is less gpu friendly?

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

#173

Post by danielsoneg » Thu, Jun 23, 2011, 9:41 PM UTC

gte910h wrote: post #159

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…

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

Right, but for the courts the question is, did they intend to violate the 4th or did they just screw up? Intent matters - in this case, whether they intended an unwarranted seizure of the server racks or if they just screwed up. Because they had a valid warrant to seize some servers from that data center, I think you'd have a really difficult time pressing the case that they Intended to violate the 4th amendment rights of the other people whose servers were on those racks. Negligence, on the other hand, is a much, much lower bar, much easier to prove in these circumstances, and should be adequate to secure damages - and frankly, I've got a lot easier time believing it was negligence in this case than an intentional violation of the other individuals' 4th amendment protections.

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

#174

Post by Xk » Thu, Jun 23, 2011, 9:41 PM UTC

kindly wrote: post #172

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 currently use a sha hash (with salt) but rehash it x amounts of times. I have changed x over the years to be larger to get an acceptable trade off in computation time. Why is bcrypt much better than this? Is it because the algorithm is less gpu friendly?

What you describe is basically PBKDF1. If you wanted to make it slightly better, you could go with PBKDF2. It's true that bcrypt is better in some ways, but you're fine with what you're doing now. If you really wanted to improve on things you could go with scrypt which eats memory also, but it's more difficult to get things to work right.

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

#175

Post by davidhollander » Thu, Jun 23, 2011, 9:44 PM UTC

tptacek wrote: post #44

cheez wrote: post #31

Earlier quoted context omitted.

Can you describe why it's better?

http://codahale.com/how-to-safely-store-a-password/ (Be prepared for your comment score to visit the grey depths if you attempt to relitigate Coda's blog post here and don't know exactly what you're talking about.)

Why is bcrypt better than simply recursively hashing SHA512 ~2^11 times to produce an equivalent work factor?

Assume wall time is held constant at 1 second per password using both methods: is there an entropy loss or weakness associated with recursive hashing that bcrypt avoids?

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

#176

Post by kragen » Thu, Jun 23, 2011, 9:44 PM UTC

tptacek wrote: post #69

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?

Secure password hashes don't protect users, and particularly not users who use one-time effectively-random passwords. Secure password hashes protect application developers from the disclosure of hundreds or thousands of user passwords from their database. It allows them to attest to their userbase "your password is cryptographically stored in a manner that makes them hard to break even by dedicated hardware; you shou…

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, there's a tradeoff between how secure your password hashing is and how much randomness users need to put into their password: every additional factor of 1000 in the iterations of the hash saves you a random character or two.

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

#177

Post by gsoltis » Thu, Jun 23, 2011, 9:49 PM UTC

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…

A variation on this is to use a random salt with each password that you store. Your auth process then becomes: 1. check the username 2: if the user exists, prepend the salt stored in the user row to supplied password, check against stored hash.

At the very least, you will make it harder for someone to crack all of your passwords by computing one table with a single salt.

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

#178

Post by dragonsky » Thu, Jun 23, 2011, 9:50 PM UTC

getsat wrote: post #36

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

> can brute force millions Modern consumer video cards can do billions per second now. You might as well just store them in plaintext instead of using SHA1/MD5 with or without salting. :/

As they have the Web code base, you must assume that they have the salt to the hashing... If they actually want to get these passwords, all they have to do is generate rainbow tables using SHA1 and the appropriate salt. We're back to relying on the length and bit depth (range of characters) of the passwords you are trying to find.

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

#179

Post by tptacek » Thu, Jun 23, 2011, 9:55 PM UTC

gsoltis wrote: post #177

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…

A variation on this is to use a random salt with each password that you store. Your auth process then becomes: 1. check the username 2: if the user exists, prepend the salt stored in the user row to supplied password, check against stored hash. At the very least, you will make it harder for someone to crack all of your passwords by computing one table with a single salt.

If you are using "salts", you have to make them random for each stored password. But if you are doing this securely, you don't care about this detail, because the bcrypt library took care of it for you.

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

#180

Post by maw » Thu, Jun 23, 2011, 9:59 PM UTC

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.