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

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

#91

Post by Xk » Thu, Jun 23, 2011, 6:29 PM UTC

joevandyk wrote: post #82

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

So if I'm using SHA-1 already to store passwords, what are my options for moving to a different system? I assume there's no way to rehash the passwords?

You have two choices that I see:

1. The next time a user logs in to your system and you verify against the SHA-1 hash that they are who they say they are, recompute the correct hash for bcrypt. Then, delete the SHA-1 hash. It does you no good to have a bcrypt version if you keep the SHA-1 version around.

2. Generate the bcrypt hash from the SHA-1 hash. That is, pretend that the SHA-1 hash is the user's password. This isn't as clean (your password authentication software will then have to do SHA-1 followed by bcrypt) but it means you'll be able to migrate your entire database all at once if you so choose. This also causes a very (very, very) slightly higher chance of password collisions, although there's not much to worry about from that.

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

#92

Post by tptacek » Thu, Jun 23, 2011, 6:30 PM UTC

thaumaturgy wrote: post #84

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…

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.

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

#93

Post by Hawramani » Thu, Jun 23, 2011, 6:34 PM UTC

mwytock wrote: post #67

getsat wrote: post #36

Earlier quoted context omitted.

> 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. :/

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?

If my understanding is correct that's not the issue here. Hashes are meant to be one-way functions, the developer can easily check if a user's password matches the hash, but it should be practically impossible to deduce the password from the hash.

What the user chose as their password should be irrelevant if using a good hash.

[Edit: I stand corrected on the effect of password length.]

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

#94

Post by StavrosK » Thu, Jun 23, 2011, 6:34 PM UTC

tptacek wrote: post #60

seiji wrote: post #52

Earlier quoted context omitted.

scrypt slides: http://www.tarsnap.com/scrypt/scrypt-slides.pdf Takeaway: Cost to crack one MD5 password: $1. Cost to crack one scrypt password: $50M to $200B. You want your login to be slow compared to the rest of your application. It's okay to take half a second to verify a login.

scrypt is better than bcrypt, but not by the same margin that bcrypt is better than salted hashes. Salted hashes are a straight-up vulnerability. bcrypt is a best practice. Note that almost nobody uses scrypt. We don't recommend it, not because it's insecure, but because it's painful to implement for most companies. But use either. Or just use PBKDF2. All of the adaptive hashes are fine .

> Salted hashes are a straight-up vulnerability.

I find this a bit of a misnomer. I understand what you mean in context, of course, but, strictly speaking, bcrypt is a "hash", and "salted" is always good.

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

#95

Post by StavrosK » Thu, Jun 23, 2011, 6:36 PM UTC

Xk wrote: post #91

joevandyk wrote: post #82

Earlier quoted context omitted.

So if I'm using SHA-1 already to store passwords, what are my options for moving to a different system? I assume there's no way to rehash the passwords?

You have two choices that I see: 1. The next time a user logs in to your system and you verify against the SHA-1 hash that they are who they say they are, recompute the correct hash for bcrypt. Then, delete the SHA-1 hash . It does you no good to have a bcrypt version if you keep the SHA-1 version around. 2. Generate the bcrypt hash from the SHA-1 hash. That is, pretend that the SHA-1 hash is the user's password. Thi…

Or you can do both, migrate everything to bcrypted SHA for now and then replace these with straight up bcrypt the next time the user logs in.

You ostensibly have a hash method identifier per hash, so just create "sha+bc" and "bc" along with your current "sha".

Also, why is the risk of a collision greater? It seems to me that, if anything, it should be lower, as SHA hashes always consist of a fixed number of bits, and thus aren't as likely to collide when hashed to bcrypt, assuming the length of a bcrypt hash is the same (or larger) number than a SHA one.

Basically, it seems to me that, if they're going to collide, they're more likely to collide at the SHA level, which is a problem either way.

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

#96

Post by thaumaturgy » Thu, Jun 23, 2011, 6:37 PM UTC

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.

OK. By the way, in case you haven't heard it lately, thanks for hanging around and demystifying this stuff for so many people. It's a huge help.

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

#97

Post by rcthompson » Thu, Jun 23, 2011, 6:40 PM UTC

rosser wrote: post #51

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?

On my collocated server, I use encrypted LVM for all of my filesystems (except /boot, of course). On my next hardware upgrade cycle, I'm going to install a USB gyroscope (inside the chassis, using one of the front USB headers) and write a daemon that will issue a `umount -lfa && halt -n` if the box is ever moved. Note that this isn't simply to keep prying eyes off my data; I live near an overdue earthquake fault line…

Shouldn't you throw in a `sync` before halting?

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

#98

Post by nkassis » Thu, Jun 23, 2011, 6:41 PM UTC

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…

I'm guessing they could have asked to take the whole rack as to not have to tell the hosting company about the raid and risk alerting the target. They also did the raid in the middle of the night which shows they were probably trying to avoid alerting the target.

They probably didn't have anyway to know which machine it was just which rack it was. They also probably didn't have to tell the hosting company directly just the facility that they were raiding.

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

#99

Post by rchowe » Thu, Jun 23, 2011, 6:42 PM UTC

Hawramani wrote: post #93

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?

If my understanding is correct that's not the issue here. Hashes are meant to be one-way functions, the developer can easily check if a user's password matches the hash, but it should be practically impossible to deduce the password from the hash. What the user chose as their password should be irrelevant if using a good hash. [Edit: I stand corrected on the effect of password length.]

But there are rainbow tables, or tables of all of the MD5s/SHA1s/ for arbitrary strings. So the time's already sunk in.

8 days for one password is a very short amount of time comparatively (tiny for a botnet). If you use bcrypt, which you can force a certain complexity on, you can get that amount of time up much higher.

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

#100

Post by boucher » Thu, Jun 23, 2011, 6:43 PM UTC

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.

And not servers hosted in other countries? I'd be very curious to hear the thought process behind that decision.