[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 4 Jul 2007 10:12:57 +0100
From: "Larry Bonner" <larry.bonner1@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Incremental mode limited to 8 character words?
> No, that's not a good reason. Why should it be?
because its a simple fact, more people have access to multi-core processing
or multiple machines
in order to carry out a faster attack against hashes..just think of "zombie"
computers installed with
a password cracker capable of distributed attacks on hashes.
8 characters is nothing with todays computing power available.
A valid reason would be password algorithms and/or
> system configurations which force password length > 8,
> because then, john's incremental mode wouldn't be
> useful.
i don't disagree with you, but how many do you know enforce length > 8?
sometimes that is the minimum/maximum required length, in order to recover
easily.
Or, it never gets there.
that can apply either way the sequence is computed, i don't see how the
order in which its done is any "better" than
the other.if they both compute the same strings.. then its only a matter of
time.
both ways can have advantages, PPro method has its advantage when attacking
NTLM1 initially, because of the way MD4
was designed.
By only modifying the first byte each time the password string is updated,
we have cut md4 processing by almost 50%
up to length 10, and further reductions can be made after, by pnly changing
the last byte of the password string instead..this
works very well in practice.
the "shortcut" isn't possible if updating the last byte of the password
string from start to end.
1 - 10
AAA
BAA
CAA
10 - ?
AAA
AAB
AAC
You are assuming you will be able to search the complete
> key space in a reasonable time.
> This is only true for poorly designed password hash
> algorithms.
but don't you see that you're making assumptions on what constitutes a
"weak" password?
i am not assuming i can personally search a whole keyspace, but are you
assuming somebody
else can't? with access to lots of machines? the reality is, there are
attackers out there
with access to sometimes literally, millions of computers.
> Even if you assume you can try one million passwords per
> second (which isn't true for many of the algorithms
> supported by john), you'll probably not be able to
> search the complete key space.
again, this is where distributed computing can be applied, break up the
keyspace,
and compute 1 million or more keys a second.we know it can be done already.
it doesn't necessarily have to be done using JTR, plenty of people out there
could
write their own crackers to do the job just as well.
> Assume 95 different characters.
> ...
> I'm sure almost any password will be of little use
> after 210 years.
> ...
> And if you have salted hashes, you'd have to multiply
> the time by the number of different salts.
>
well, obviously not everyone is going to use all available 95 characters
on the keyboard..in fact i can only count about 92 and when i choose a
password,
its usually made up of just letters/numbers, thats about 62 characters if
you consider
upper/lowercase combinations.
its nice that people have choice of all available characters on keyboard,
but truth is most people will
likely use characters for a password thats easy to remember..thats where the
weakness is
usually.not in the algorithm itself, or how many bits the key length can be.
so, enforce a good password policy? again, this doesn't happen in real life
so much.
> Weak passwords are those an attacker can find in a
> reasonable time.
> All passwords with a length of 3 are weak, IMO.
i was giving an example of the way in which PPro creates password strings,
not what is a good password length!!!
If you can just try a small fraction of the key space,
> the order in which you try the candidates becomes important.
> What's the point of looking for weak passwords in poorly
> designed hash algorithms?
whats the point in having password crackers, full stop?
what i meant by "poorly designed" is that there are what i term shortcuts.
ways to optimize computing a hash to a password by reversing the ciphertext
up to a certain point, like
you can see in mdcrack source code for md4/md5...or finding the
password to a hash through simultaneous encryption/decryption.
never thought about doing encryption/decryption at the same time?
some might say there is no point, but atleast on archs with lots of
registers, you can break up
dependencies and increase performance overall.
obviously x86 wouldn't be suitable, but x64 might be..
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
