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

201–210 of 263 posts

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

#201

Post by caf »

encoderer wrote: post #153
rubinelli wrote: post #147

Earlier quoted context omitted.

Generating the salt from the password completely defeats its purpose. Users with the same password will have the same salt, and therefore the same hash. In your example, an attacker could find which users chose the password "password" by running your hashing algorithm with a salt value of "pasord". Your database would be wide open to rainbow table attacks.

Right, so then the idea is that if they get your DB dumb, and see this salt scheme in your code, they can compute a rainbow table using it and now they have cracked all your passwords in the time it would take to brute force one (well, not really, because it's not as if they'd have to brute force the entire keyspace before they got to the one password they're trying to break, but I think I'm onto the right idea about…

Effectively you are still using a hash without a salt, it's just that you've created a new, non-standard, hash function.

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

#202

Post by protomyth »

m0nastic wrote: post #115
tptacek wrote: post #23

Earlier quoted context omitted.

I don't think the IT skill required to reliably extract evidence from an arbitrary hosting operation (of potentially arbitrary complexity) is simply "on tap" for the FBI. If you want to say "tough luck that's just what it costs to collect evidence in 2011", fine, but it's probably not fair to say that the FBI should just naturally have that capability.

In general the FBI is still operating in a pre-datacenter mindset when it comes to evidence acquisition. It wasn't until 2007 that they updated the Handbook of Forensic Services[1] to no longer require seizing peripherals of suspected evidence. Think about that for a second, that means mice, keyboards, monitors, etc. The team who worked on this raid ironically is part of the DOD CCC, which is a joint forensic lab set…

How is the DOD allowed to work on civilian law enforcement in any capacity?

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

#203

Post by caf »

derrickpetzold wrote: post #181
Xk wrote: post #171

Earlier quoted context omitted.

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

That is fair enough and all your points were very good. However despite the down votes and everything else I stand by what I said. As a user I doubt most devs are as competent as the ones here and I would never trust a site with a password that I depend on. Do that there would need to be third-party auditing to make sure that they adhere to the standards you described. I guess what I am really trying to say is that t…

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).

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

#204

Post by protomyth »

smackfu wrote: post #118

To be clear, the server stopped responding, and the host he is paying for the server has not responded at all. The server could simply be unplugged, or all the network cables were unplugged during the raid. Who knows? I guess "The FBI stole my server is a better headline" though. In my experience with our leased data center cages, we are expected to fly in to town if we ever need to physically manipulate the servers…

If DigitalOne's people are out of country, a truly evil tactic for the FBI would be to ask customs to reject any reps entry.

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

#205

Post by m0nastic »

protomyth wrote: post #202
m0nastic wrote: post #115

Earlier quoted context omitted.

In general the FBI is still operating in a pre-datacenter mindset when it comes to evidence acquisition. It wasn't until 2007 that they updated the Handbook of Forensic Services[1] to no longer require seizing peripherals of suspected evidence. Think about that for a second, that means mice, keyboards, monitors, etc. The team who worked on this raid ironically is part of the DOD CCC, which is a joint forensic lab set…

How is the DOD allowed to work on civilian law enforcement in any capacity?

I'm not sure exactly what you mean, but the Defense Department works with other government agencies and non-governmental agencies; and has for quite a long time.

One of these collaborations is responsible for you being able to type that comment and have it be readable by someone on another computer.

As to the specifics of the DOD CyberCrime center, it was set up in 98 to offer training/services to other law enforcement and counterintelligence agencies.

Basically, someone figured that instead of having to have each seperate agency stumble around in the dark dealing with cyber crime, they could pool resources and try to standardize. It's actually a pretty good example of getting rid of beaurocracy.

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

#206

Post by derrickpetzold »

caf wrote: post #203
derrickpetzold wrote: post #181

Earlier quoted context omitted.

That is fair enough and all your points were very good. However despite the down votes and everything else I stand by what I said. As a user I doubt most devs are as competent as the ones here and I would never trust a site with a password that I depend on. Do that there would need to be third-party auditing to make sure that they adhere to the standards you described. I guess what I am really trying to say is that t…

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.

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

#207

Post by cheez »

danielsoneg wrote: post #173
gte910h wrote: post #159

Earlier quoted context omitted.

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

"Uh sorry, I didn't mean to do that."

"Oh, phew, carry on."

You're kidding me, right?

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

#208

Post by Nick_C »

rcthompson wrote: post #97
rosser wrote: post #51

Earlier quoted context omitted.

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?

If you do that, I would change && to ; on the basis you want the halt no matter whether the umount succeeds or not.

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

#209

Post by vl »

Xk wrote: post #109
Hawramani wrote: post #93

Earlier quoted context omitted.

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.]

SHA-1 is a reasonably good hashing algorithm, but for the sake of argument, I'll talk about an imaginary SHA-4 which is perfect in every respect. It will be a 4096 bit hash function which has no faster-than-bruteforce collisions or preimage attacks or second preimage attacks. Let's also assume that this perfect SHA-4 function is freakishly fast, say, a million times faster than SHA-1. Now, even though my imaginary SH…

>Let's also assume that this perfect SHA-4 function is freakishly fast, say, a million times faster than SHA-1

This is why they invented key stretching: http://en.wikipedia.org/wiki/PBKDF2

Just set number of rounds to 10000000000 instead of, like, 10000 for SHA1.

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

#210

Post by JonnieCache »

rdl wrote: post #191
oskarkv wrote: post #146

Earlier quoted context omitted.

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.

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.
Post reply on HN