The DMZ - 2012-08-09 (page 3 of 3)

« first day (602 days earlier) ← previous day next day → last day (4283 days later) »

9:03 PM

@Iszi “The attacker now has an easier job: he can find any password whose hash begins with 2c26b46b68ffc68ff99b453c1d304134.”

and “The only way to invert a proper hash function is by straight brute force: guess the password, compute your guess's hash, compare with the reference hash. If the reference hash is a truncation of the real hash, the attacker gains a negligible amount of time doing the comparison. For a massive brute force attack, or if you truncate the hash too much, the attacker may have its job made easier by finding a collision on the truncated hash which wouldn't have been one on the original hash.”

@Gilles Yeah, that does a good job of explaining how the attacker's job is easier. (Though, for me, there are some readability issues.) However, what I was interested to see, and @ThomasPornin did a good job of spelling out in his edit, was a direct answer to the original headline: "Does truncating the hash make the password harder or impossible to crack?" Targeting the actual password, the answer is yes.

Addressing the latter part of the question though "are there problems with this" is what most of the answers have done - and the answer to that is absolutely, because truncating the hash means that there are a whole lot of other passwords that will now be valid.

@Iszi No! The answer is no

@Gilles Oh?

Assuming the password has less entropy than the truncated hash

which is always going to be the case in practice

I don't follow.

9:09 PM

Ok, then I'm not doing a good job of explaining it

One of the assumptions in the question is that it's a good hash that's being truncated

@Gilles Good hash, plus salts, etc.

@Iszi good password hash function, something like PBKDF2

but actually that doesn't matter, the answer would be the same for SHA1

The point is that the only way to find the password is by brute force

I assume that the hash function is not invertible in practice

The point of salt is to make brute force attacks harder because you can't factor the work. However this is irrelevant here.

Okay... still not seeing my flaw in logic.

So: the attacker will look for the password by making a guess, computing truncate(hash(guess)), and try again if truncate(hash(guess)) != reference_truncated_hash

the attacker stops when truncate(hash(guess)) == reference_truncated_hash

ok so far?

Agreed.

9:14 PM

so now the question is whether this guess is the actual password

Exactly. Irrelevant now, from the attacker's perspective, but still part of the question.

if hash is a decent cryptographic hash function (e.g. one of the SHA), the password is memorable by a human, and the length of the truncation is decent (e.g. 16 bytes), then I claim that it is

So, you're saying that a truncated hash is, in effect, equally collision-resistant as the full-length hash?

@Iszi Not equally, but proportionally (for some approximation of proportionally)

@RoryAlsop had to publicly disagree with you, I think this is the 2nd time...? discuss.area51.stackexchange.com/questions/5511/…

9:17 PM

In an ideal hash, all the bits are independent: if you have 3 bits of the hash, and you're looking for a preimage, the best you can do is discard 1 guess in 8

Interesting. I think @ThomasPornin's answer speaks contrary to that though.

For the SHA family, this is widely believed, and quantified by NIST

csrc.nist.gov/publications/nistpubs/800-107/NIST-SP-800-107.pdf

This is quickly getting over my head. I'm still interested to learn, but starting to get too deep.

for example, if you take half of SHA-512, that's as good as taking SHA-256

If you take half of SHA-256, or the first 16 bytes of SHA-1, you have the same security that you'd have with MD5 if MD5 wasn't broken

@ThomasPornin Maybe you could help a bit, when you get back? I'm particularly interested in your response, since I believe your edited answer appears contradictory. chat.stackexchange.com/rooms/151/conversation/truncated-hashes

@Gilles But that sounds like it's still not as collision resistant as using the full hash instead?

9:21 PM

@Iszi Yes. You take half the hash, you get half the collision resistance

@Gilles And that's exactly the point I was looking for. With more collisions to contend with, it's a lower SNR and therefore more difficult to determine which is the actual password.

@Iszi yes, but with a 128-bit hash, you have 2^64 collision resistance

and by the time the attacker finds the password, he's made a lot less than 2^64 attempts, because real-life passwords have less entropy than that

If the attacker finds a collision, he's broken the hash function

I think I'm starting to follow, but would really be interested in another perspective to help clarify. What you're saying is that, while technically the actual password should be harder to guess, the natural weakness of human-generated passwords nullifies (and perhaps even overwhelms) this benefit?

Briefly, on another topic, is this one perhaps a bit too S&M?

0

Q: Is it more or less secure when an entity shares it's security procedures?

Right now I'm doing a work term through my school and they want me to right a report on something I've worked on. They are really serious about "proprietary reports" and reports requiring destruction after they've been marked. I'm planning to right about becoming PCI compliant and my boss tells m...

(Reminds me, another meme to define...)

@Iszi I think that's fine

we have a similar question about open source

@Iszi Suppose that the data being hashed was a long, random message. Then neither the original hash nor the truncated hash can guarantee that a candidate message is correct.

However, we have confidence in hashing functions because we believe that we will not find collisions.

If we ever do find a collision, our confidence in the hash function will be shattered, or at least badly dented

see: MD5

@Gilles I presume by "long", you're now referring to "longer than the hash output"?

9:32 PM

@Iszi yes

Or more precisely, with more entropy than the hash output

i.e. it takes more bits to describe the original message than the hash

@Gilles but in this case, the collision is forced, by the truncation, and not in the hash itself. No?

@AviD I'm getting to that

@Gilles oh, a donkey jumps on his head.

By truncating the hash, you reduce the number of buckets, so there have to be more messages on the same bucket

Let's take an extreme example: the hash is truncated to 8 bits

Then the attacker will find a preimage for the truncation in an average of 2^7 tries

that preimage is highly likely not to be a preimage for the full hash

And the attacker can go on and generate more preimages for that 1-byte hash

and he will have no idea which one matches the full hash, since he doesn't know the full hash

The same goes for a longer truncation, if there are sufficiently many possible messages

However, keep in mind we're now talking about an attacker who can verify 2^127 guesses

If that attacker was possible, we wouldn't use SHA-256

@AviD Welcome back again. Sorry about the noise. ;-)

9:37 PM

@Iszi heh. it wasnt you, it was @xce! (kidding, kidding. Really.)

I think I've posted more here today than ever before

@AviD You think we'll have to start keeping one of these around?

user image

3

@Gilles I'm considering blaming @xce, just so I can turn him into a new meme....

@Iszi hehe, luvvit!

@Iszi I should get one of these for work

and three for my private life

(or, how to lose friends)

9:59 PM

@RoryAlsop re the blackhat contest week, there is a problem with that...

without getting back into the discussion of whether or not it should be allowed here, and without getting into the other sucky proposal

blackhat is not a topic.

and before you say it, it shouldnt be a tag, either - that would make it a meta-tag.

I do like the proposal (was it @Polynomial?) of having a native week.

@AviD how about attacks, exploits?

@Gilles that doesnt make it blackhat.

@AviD true, the tags can be about existing exploits rather than crafting your own, and so on

which, by the way, argues my point that the two belong on the same site

@Gilles i think that while that tag was in use, it was mainly used for incidents. I.e. I just had an exploit.

@Gilles that part I dont disagree with.

in fact, I dont think there is room at all for a 2nd site - either here, or not at all. I think we just dont agree about the not at all part.

@AviD yeah, it's Rory I want to convince

10:13 PM

@Gilles actually, it looks like that proposal is gonna go live regardless of what @RoryAlsop thinks.

I think we need to flag that proposal for SEI staff.

@AviD hah! It isn't even in commitment yet, though it'll probably go there

one of the answers on that q suggested making it a "lifehacker" type of site. I think that's the only idea there worthy of pursuing (for them) - otherwise it's other duplicated (by us or Repurposing), illegal (or otherwise problematic), or just plain ambiguous and confusing.

@Gilles erm, I meant get to commitment.

because it has such a vague description that several unrelated communities claim it

yes, I found that amusing.

sure sign that it should be nuked.

Worth mentioning to RC

Better you than me, they're used to me complaining about stuff

I'm usually right, but that's no good when the dominant voice prefers to head towards the wall head first

10:18 PM

@Gilles heh. right now I'd seem to be one of those heads, seeing as one of my junior co-moderators is in senseless disagreement with me.

@AviD we should start with a Discuss.Area51 post

But it would help to have a black hat policy here first

@Gilles another one?? its already been done over and over again, they dont seem to get it.

So that we can tell people “this stuff is already on-topic on Sec.SE”

@Gilles I agree.

@Gilles and if its not, it shouldnt be on any SE at all.

Actually, there are two issues: the vague description, and the overlap with Sec.SE

10:21 PM

@Gilles actually the vague description leaves more than two issues.

@AviD hello - am I in a minority on this :-(

the vague description, but also depending on how you try to interpret it - overlap with sec.se, overlap with repurposing, overlap with illegality and improperness.

the repurposing proposal I really like

292

Computer Security Hacking!

Proposed Q&A site for experts/hobbyists who identify weaknesses in systems/designs, use irregular methods, create undocumented processes, test for weaknesses/methods to subvert IT security, have problems with cited techniques or using inventions specific to this testing.

Currently in definition.

@RoryAlsop of course you are - but if it makes you feel better, I'm just pretending to disagree with myself, so people stop accusing us of being sockpuppets. .

10:22 PM

Oh, the title and description have changed!

@AviD lol

Ok, so now a bunch of questions need to be closed as off-topic

actually, no one has in quite a while now.

meme?

And the overlap with Sec.SE becomes a clear issue

@Gilles hehe, and the circle begins again.

@Gilles absolutely

all except for "use irregular methods"

10:24 PM

@Gilles yeah, almost explicitly now

@AviD yep - I'm on it

I think also "create undocumented processes" would be counter to our usual stance.

@RoryAlsop me too.

@AviD aren't you bear #3 and bear #4 in disguise?

@Gilles tiggers arent bears!

2

@AviD oh my

lol, howd I miss that??

we already have the lion on the site....

10:26 PM

hahahaha

@AviD blackhat as a topic - it is out there for discussion at present. attacks and exploits work for me though

wondering whether @Gilles' wonderful "Welcome to the site" messages to people with high reputation could also go on the meme list. As long as I can find more victims than just that one I think it's good to go

@RoryAlsop AFAIR I've used it with two people: D.W. here and IVA on U&L

ahhh - maybe it would seem a bit rude to highlight it here then :-)

IVA got the hint, after a while he increased his typical post length from 1 line to 3

it makes me really laugh out loud though

10:44 PM

> You have already voted to close this question

Oh, Area 51 votes expire!

No wonder it's difficult to close questions there!

@RoryAlsop see our comments above - those tags dont mean its blackhat.

like i say, it's a tricky "topic" for the week.

@AviD someone suggested migrating stackoverflow.com/questions/11865686/penetration-testing here in the TL

that is sooo off topic for SO...

dont think its much of a question though.... pretty much narq.

11:03 PM

@Iszi I CAN FILL IN

BASICALLY, BEAR #1 IS CORRECT (AS IS CUSTOMARY)

@Gilles SAYS: IF THE PASSWORD HAS LOW ENTROPY, THERE ARE LESS PASSWORDS THAN POSSIBLE HASH OUTPUTS, EVEN POSSIBLE TRUNCATED HASH OUTPUTS.

SO THERE IS (WITH HIGH PROBABILITY) ONLY ONE "CANDIDATE"

(CANDIDATE = PASSWORD WHICH MATCHES THE HASH VALUE)

SO IF YOU FIND A CANDIDATE, THAT'S THE ONE. TRUNCATION CHANGED NOTHING.

THIS IS VALID ONLY IF THERE ARE INDEED MUCH FEWER POSSIBLE PASSWORDS THAN HASH OUTPUTS, E.G. NO PASSWORD OF MORE THAN 20 CHARACTERS OR SO.

AND TALKING ABOUT COLLISIONS HERE IS JUST ADDING CONFUSION; THE PROBLEM IS ABOUT PREIMAGES.

THE BEAR HAS SPOKEN. ALL HAIL THE BEAR !

4

11:31 PM

ALL PRAISE HYPNOBEAR

Wow. When did Little Bear get his CAPSLOCK stuck?

Small Bear is the anti-TR. He speaks loudly enough to not need a stick.

« first day (602 days earlier) ← previous day next day → last day (4283 days later) »

Transcript for

Aug '129

The DMZ

A serious place where infosec is discussed PS we don't do hard...

404-errors moderate-anarchism pretending-to-work staring-into-the-abyss

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile