[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP46082F711472F5691BB64E2FD390@phx.gbl>
Date: Sun, 15 Apr 2012 23:19:53 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: .chr files
On 04/14/2012 12:29 AM, magnum wrote:
> On 04/13/2012 08:51 PM, Frank Dittrich wrote:
>> If you do have a bias in the passwords which serve as input for
>> generating a .chr file, using this .chr file for incremental mode will
>> increase that bias. If this bias doesn't exist in the passwords which
>> are still uncracked, you'll have generated a less than optimal .chr file.
>>
>> For the same reason, you might want to reduce the impact frequently used
>> passwords will have on your .chr file.
>> E.g., if you crack DES password hashes, and you have 4096 different
>> hashes for "password" on your .pot file, 8 character passwords starting
>> with "p" will be over-represented in the password candidates tried
>> first, and so on.
>
> Interesting. I have had the idea you should use unfiltered john.pot for
> making the chr files. But maybe this is just a bad idea in general, for
> the very reason you give here.
If you have a large database of cracked passwords, and you do have no
knowledge about what password cracking attempts have already been tried
against a new set of hashes, I think it is OK to keep most of your
john.pot contents as is when generating a new chr file.
I'd just filter out obvious bogus entries (like, 4096 DES hashes for the
password "{empty}", to make sure I don't waste a lot of cracking time on
passwords of length 7 starting with character '{').
If your database is large enough, you'll probably have accumulated a
large set of patterns so that an individual pattern will not have that
much of an influence on the frequency.
Because if you know nothing about this new set of passwords, it is not
unreasonable to assume that the new passwords will somehow resemble the
passwords you did crack in previous sessions. And this assumption is
best reflected in he existing john.pot file.
(Of course, even this approach is comparable to a self-fulfilling
prophecy. You'll definitely find what you are searching for.
So, if your past password cracking attempts were less than optimal and
you missed cracking a lot of easy to crack passwords, your john.pot file
will still be a poor choice for building a chr file.
The same applies if you have a chr file which usually works very well on
a new set of passwords, but this time you detect that, for some reason,
those new passwords are quite different from what you were used to find.)
But normally, you'll not try to crack all the new password hashes just
relying on incremental mode.
Instead, you'll at least try some commonly used passwords and some other
patterns first, because you expect them to be very successful.
If you know you'll try all the DD/MM/YYYY combinations from 1900 to 2012
anyway, then you should exclude all the passwords matching his pattern
when generating a chr file. Since you exhaustively searched this part of
the total key space, these passwords can safely be removed when
generating a chr file.
(Nevertheless, you'll finally try those passwords even in incremental
mode, but hopefully much later than you would if you had not removed
these passwords.)
Frank
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.
