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

191–200 of 263 posts

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

#191

Post by rdl »

oskarkv wrote: post #146
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'm just wondering: What if I used SHA-1 a million times on the password, i.e. hashing the hash over and over. Wouldn't that make it much more time-consuming for an attacker? Or am I missing something? The input every time but the first would be a random-looking 160 bit number, so it would be hard to guess. And if the attacker wanna look for common passwords in a dictionary the attacker must hash them a million times…

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.

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

#192

Post by [deleted] »

oskarkv wrote: post #146
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'm just wondering: What if I used SHA-1 a million times on the password, i.e. hashing the hash over and over. Wouldn't that make it much more time-consuming for an attacker? Or am I missing something? The input every time but the first would be a random-looking 160 bit number, so it would be hard to guess. And if the attacker wanna look for common passwords in a dictionary the attacker must hash them a million times…

[deleted]

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

#193

Post by m0nastic »

gwright wrote: post #188
m0nastic wrote: post #170

Earlier quoted context omitted.

I can certainly think of scenarios in which this action was reasonable from the FBI perspective. I don't like to be in the position of defending the FBI (my own personal and professional relationship with them is complicated), but I think the following situation is plausible (which isn't to say it's what happened, as we don't know): FBI determines the originating IP address of whatever their investigation is targetti…

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 perform this acquisition and were able to deduce that the targets you were going after were blades in an HP chasis in a specific rack, and let's say those blades aren't identifiable within the chasis (like oh say, maybe the IP address isn't noted), it might be within reason to take the chasis and all the blades for that specific chasis.

It might also be within reason that if you can identify which specific blades are part of your acquisition, you take those, and also the chasis they are plugged into (but not the other blades, although they are now sitting on a table in a datacenter somewhere, not plugged into anything).

All we know is that customers of that same provider who were stored in the same datacenter were taken offline. Marco doesn't actually know that his blade server was physically taken, he just knows that it was brought offline.

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

#194

Post by pyre »

tptacek wrote: post #28
[deleted] wrote: post #15

[deleted]

I didn't downvote you, but your "If you're the FBI and you want X, you'd simply Y" has nothing to do with reality. In reality, when any law enforcement organization needs digital evidence of any kind, they take everything. There are chain-of-custody rules that require it.

But is all of the collateral damage that results in the public's best interests?

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

#196

Post by angusgr »

ahi wrote: post #158
getsat wrote: post #81

Earlier quoted context omitted.

You're looking at more like 5+ billion/sec today. There was a listing of modern consumer video cards + their hashing capabilities posted on another HN story recently, but I can't find it.

https://en.bitcoin.it/wiki/Mining_hardware_comparison Not sure if this is what you were looking for or the particular hash bitcoin uses, but a $110 Radeon 5830 can get you around 250Mhash/s

"Hashes" aren't interchangeable, they're an abstract concept. In this case, the thread is talking about the SHA-1 hash algorithm. AFAIK Bitcoin uses SHA-2 w/256-bit digests.

So, actually, in this case the two happen to be related but different - SHA-1 being considered potentially flawed but not (yet) the stronger SHA-2.

Also, the Bitcoin block headers that are hashed are (I think) 80 bytes (640 bits) long, salted passwords probably a bit shorter.

Wikipedia says SHA-256 runs about 2/3 the raw throughput of SHA-1. You can the comparative rate yourself on any nix computer:

$ openssl speed sha1 sha256 -snip- Doing sha1 for 3s on 16 size blocks: 7760096 sha1's in 2.99s Doing sha1 for 3s on 64 size blocks: 5502820 sha1's in 3.00s -snip= Doing sha256 for 3s on 16 size blocks: 5460366 sha256's in 3.00 Doing sha256 for 3s on 64 size blocks: 3169031 sha256's in 3.00s -snip- *

So... about 2/3 faster. I don't know enough about crypto implementation, but I'd guess this ratio would scale roughly to the much faster GPU implementations as well.

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

#197

Post by tptacek »

davidhollander wrote: post #175
tptacek wrote: post #44

Earlier quoted context omitted.

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?

Look at PBKDF2:

http://www.ietf.org/rfc/rfc2898.txt

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

#198

Post by daeken »

IgorPartola wrote: post #79
tptacek wrote: post #73

Earlier quoted context omitted.

There is virtually no chance that, after selecting bcrypt, you will be forced to scramble to replace it in 2 months. There is no chance that, after selecting bcrypt, you will be forced to scramble to replace it with salted SHA-1 hashes. bcrypt is strictly better than what you're doing now.

Fantastic. One more question: does increasing the work factor automagically upgrade existing passwords in some way? As in, will bcrypt passwords created today be strong enough in 2020?

getsat and tptacek have already answered your question, so I won't rehash that (pun wholly intended), but I should point out that one interesting property of PBKDF2 is that you can increment the work factor (number of iterations).

PBKDF2(password, iterations=10) == PBKDF2(PBKDF2(password, iterations=5), iterations=5)

Thus you could, say, increase the number of iterations every month. All that said, you should still use bcrypt; this is just an interesting property IMO.

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

#199

Post by sunchild »

kragen wrote: post #176
tptacek wrote: post #69

Earlier quoted context omitted.

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

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.

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

#200

Post by protomyth »

InnocentB wrote: post #162
pavel_lishin wrote: post #116

Earlier quoted context omitted.

Thanks, printed it off, will try to read on the train.

Sounds like a good use case for Instapaper :P

Might not want the FBI to know he read the article if they come back for a "followup visit"
Post reply on HN