[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP32509E1C5AC553DF1346B7BFDD00@phx.gbl>
Date: Thu, 12 Jul 2012 12:44:40 +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:29 PM, Aleksey Cherepanov wrote:
> On Thu, Jul 12, 2012 at 12:01:28PM +0200, Frank Dittrich wrote:
>> I just looked more closely at your t.pl script.
>>
>> If I understand that correctly, you want to copy all the files needed
>> for a particular attack into a subdirectory (named like the attack) in
>> the "store", which is a directory on the client side.
>>
>> I'm afraid that's not really practical.
>> Users can have huge word list files like rockyou.txt,
>> facebook-names.txt, or even a collection of all words from a wikipedia dump.
>> If you always copy these files for every new attack (cracking a set of
>> hashes of a different fast and saltless format, or trying rules from
>> another [List.Rules:...] section, this will not only take time, the user
>> might also soon run out of disk space.
>
> It is a bug. I do not want to copy file for each attack. I intend to
> copy file once, only for the first attack. Then wrapper would replace
> reference to that file with reference to file in the store in subdir
> of the first attack that used this file.
But in this case you have a problem if the user changes the content of
that file between attacks.
> Though even one copy could be too big. I think in some cases it is
> possible to use hardlinks.
Do hard links work on Windows? If not, is that important?
If I look at the windows specific targets in the make file, it doesn't
look line hard links are supported:
../run/unshadow.exe: symlink.c
$(CC) symlink.c -o ../run/unshadow.exe
strip ../run/unshadow.exe
>> Another problem is your "short test run".
>> You should verify if the command line parameters really describe an
>> attack, before you do git add ..., git commit ..., git push ...
>> What is a short test run? For GPU formats, even processing the first
>> block of MAX_KEYS_PER_CRYPT candidate passwords can easily take several
>> minutes.
>
> You proposed short test run to verify options:
> http://openwall.com/lists/john-users/2012/05/23/1
Yes, I think we somehow need to avoid that a lot of crap which doesn't
work gets stored on the server.
Not that implementing some checks in the wrapper would prevent a
malicious user to directly use the git commands to upload crap.
But I would ignore that case, at least for now.
I am more concerned about a user accidentally inserting a typo somewhere.
So the check could also be done by creating a new hidden option, say
--verify, to john.
If we make than hidden option accept optional parameters, we could even use
--verify=0 just check the parameter for syntactical correctness
--verify=1 additionally, check that the command line options describe an
attack
--verify=2 additionally check that there are (uncracked) password hashes
left in the input file(s), either for the first format that finds a
valid entry, or for the format specified on the command line
--verify=3 add even more checks, like: are the rules referred to by the
--rules parameter syntactically correct
...
This approach would avoid a real test run, but it has some drawbacks as
well. (Some drawbacks are the same as with a real test run.
--verify=3 wouldn't need to check the correctness of rules every time I
want to use the same rules in a different attack (different word list or
different hashes)
If we verify the command to run, a user who hasn't hardware with a GPU
cannot create and upload attack descriptions for formats implemented for
OpenCL or CUDA.
That means, he cannot create attacks for less experienced users with
more suitable hardware.
>> 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.
> More important to have options to modify attacks. I mean to make a
> copy of attack with small modifications (with automatic reference to
> original attack, to keep track of interconnections between attacks).
I don't know if it is more important now. May be later.
The drawback is that users would need to learn a new syntax, whereas
with a simple wrapper, they use normal john syntax.
They can grab old commands from bash history and modify them.
(It should even be possible to reuse john's bash completion logic with
little effort.)
> As of I intend to prevent start of already existent attack I need an
> option to force such start.
If you want to force starting such a command, just don't use the
wrapper. Shouldn't this work?
> 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?
> And of course there will be an option to start attack by name. So user
> does not need to type all options to start some existent attack.
Of course. This makes sense
> 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.
More interesting could be to identify how much several [List.Rules:...]
sections overlap. But this probably shouldn't be done by a perl script
(alone). Instead, a new helper function is needed in john to parse a
Rules section and to write the results to stdout.
> 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 think I could not predict all such small features but some
> practice will show what is needed.
I don't think this is done so frequently that it justifies support by a
script.
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.
