[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 12 Jul 2012 13:32:21 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: Aleksey's status report #12
On 07/12/2012 12:56 PM, Aleksey Cherepanov wrote:
> On Thu, Jul 12, 2012 at 12:44:40PM +0200, Frank Dittrich wrote:
>> On 07/12/2012 12:29 PM, Aleksey Cherepanov wrote:
>>> On Thu, Jul 12, 2012 at 12:01:28PM +0200, Frank Dittrich wrote:
> Test run seems to be enough good, easy and general to be implemented
> first.
Sure, the verification is not that urgent, compared to other items.
May be we can even live without verifying on the client side that the
attacks work, at least for now.
>>>> Also, what kind of wrapper parameters do you think you'll need?
>>>
>>> There will be options to overwrite config options. Just for
>>> convenience.
>>
>> Just make sure you care for the "convenience" part *after* the mandatory
>> functionality is there.
>
> I already did it in a general manner. So now all options could be
> overwritten using --config-<option>=<value> style. For instance if a
> user want to run another john (for instance gpu version) he could
> supply --config-john=john-gpu (or something like that).
GPU formats could have a different maximum password length, compared to
the CPU format, but I don't know if this relevant for the contest.
If we find that some formats have simple, long passwords like
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, we can still try those simple passwords
using a slower implementation with higher maximum password length.
(The same probably applies to CPU formats raw-sha1 and raw-sha1-ng.)
>> If you want to force starting such a command, just don't use the
>> wrapper. Shouldn't this work?
>
> Then we loose tracking of progress.
But if the same user already ran this attack, why should we care about
progress tracking for the second run?
>>> You could see that I store status of each
>>> attack in a file with user name to allow many users run the same
>>> attack (but one user could not run the same attack twice, practically
>>> he could do it and would overwrite status file, also a bug).
>>
>> Why would a user want to run the same attack more than once?
>
> For instance it could have two computers and he want to try attack on
> other computer due to speed considerations. Though user could have
> different user names in script so second wrapper would not create new
> attack and would not conflict with the first. Hm, probably I need
> additional option (like machine number) to make it less hackish.
>
>>> Also I think some additional actions could be done with options. For
>>> instance I'd make an option to calculate overlap between attack
>>> keyspaces
>>
>> This is hard to do for certain attacks.
>> Also, the key space an incremental mode attack covers is "all the
>> passwords up to the max. length, assuming you didn't forget to include
>> some of the possible characters. But usually such an attack will never
>> finish.
>
> If we get first N candidates from incremental mode it would be a
> meaningful keyspace. I think N could reflect the time before the end
> of contest multiplied by greatest speed in team. Though speed could be
> increased by --fork. So it may be better to supply N (or speed)
> manually. Because efficiency of incremental mode decreases it could be
> the case.
Let's postpone this discussion until after the contest.
I don't think that this is a god approach.
>>> Maybe some other things just for convenience. For instance simple
>>> config file management: for chr file, action to make new charset and
>>> add a section about it into config (and probably start an attack with
>>> it).
>>
>> I don't think this is done so frequently that it justifies support by a
>> script.
>
> Probably there should separate script that does so each few hours.
If you frequently generate new .chr files from a john.pot which changes
only slowly over time, you'll have a lot of overlapping password
candidates generated by each of these incremental runs, so, you'd waste
time on trying candidates that have already been tried before.
At least for the contest, a different strategy seems to be more useful,
but may be this also applies for real world pen testing scenarios:
KoreLogic already announced that there will be different patterns to be
detected.
If we detect a pattern YYYY-MM-DD and try all candidates of this
pattern, then create a new .chr file, the candidate passwords generated
in incremental mode will have a bias towards such YYYY-MM-DD passwords,
but there are no more of these passwords left to crack.
I think a better approach is:
Have a reasonably good .chr file before the contest or pen test starts.
Then, don't run incremental mode against all password hashes in a file,
but instead run it against a *random* sample of hashes (if you have
salted hashes and multiple salts, you may prefer those salts with
multiple hashes).
Let's say, you pick a *random* sample of 5% (or 20%) of all the hashes,
and you run incremental mode just against this sample.
This strategy allows to try a 20 times (5 times) larger part of the
total key space, increasing the chance to detect patterns you would miss
when just trying the smaller key space you manage to cover when
attacking all the hashes.
Instead of --incremental, you could try a similar strategy with
--markov mode.
Or even other attacks using word lists, mangling rules, external modes.
As long as your random sample of hashes is big enough, you should be
able to find out which patterns were used.
Then, just try those patterns that worked for the sample on the other
password hashes, starting with those patterns that worked best.
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.
