[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <568EB056.1050606@mailbox.org>
Date: Thu, 7 Jan 2016 19:37:10 +0100
From: Frank Dittrich <frank.dittrich@...lbox.org>
To: john-users@...ts.openwall.com
Subject: Re: get more info about what yield to crack a particular
pwd
In addition to what Rich already mentioned in his reply, some more
suggestions.
On 01/07/2016 08:53 AM, patpro@...pro.net wrote:
> - what actual word from my wordlist was used
Except when you are using --wordlist without any rules, this is
currently not possible.
May be you could create a new github issue:
https://github.com/magnumripper/JohnTheRipper/issues
and we can discuss there how this request could be supported, may be
only for debug builds, only with --verbosity=5, only with --mkpc=1 ...
Such a feature will definitely have a performance impact, so don't
expect this information to be easily available in a default build or
with a default config.
> - what rule applied to this word allowed jtr to crack the password
Since most formats work on blocks of multiple candidates at the same
time, there's always a possibility that candidates in such a block were
generated by multiple rules.
This is especially true for very short word lists or for single mode.
An additional difficulty in single mode is that even with just a single
rule ':' (e.g., with --single=none), john will try combination of words
from the GECOS field, user name ...
In recent bleeding-jumbo versions there are config variables which
control single mode behavior:
SingleWordsPairMax
PristineGecos
SingleSkipLogin
Search for these variable names in john.conf and read the related
john.conf comments.
Furthermore, single mode with default config settings will try
candidates which successfully cracked one hash on hashes with other
salts. This can be changed by Adjusting config variable
SingleRetestGuessed.
Similar to wordlist mode and single mode and their different rules,
you'll have different markov levels or different incremental mode levels
when using --markov or --incremental.
The default number of candidates in a single block depends on the format
and on the specific build.
You can check those values using --list=format-all-details
$ ./john --list=format-all-details --format=bcrypt
Format label bcrypt
Disabled in configuration file no
Min. password length in bytes 0
Max. password length in bytes 72
Min. keys per crypt 16
Max. keys per crypt 48
Flags
Case sensitive yes
Truncates at (our) max. length no
Supports 8-bit characters yes
[...]
For --single mode, john will try "Min. keys per crypt" candidates
simultaneously, for other modes, john will try "Max. keys per crypt"
candidates simultaneously, except for the last block.
If you want to make sure you will always have the "correct" rule, you
can enforce just one candidate per block by adding the following option
to your command line:
--mkpc=1
But please note that this will also cause a performance hit.
(In general, the larger a format's "Max. keys per crypt" and the "Min.
keys per crypt" valueS, the more --mkpc=1 will impact performance.)
So it might be a better idea to convert your .pot file into a dummy hash
file.
E.g., just use --format=dummy or some other fast format.
The dummy format just uses the prefix $dummy$ followed by the password
converted to hex, e.g., password "dummy" would have hash
"$dummy$64756d6d79".
If you use some other format, make sure it supports at least the same
password length as the format(s) in your .pot file.
If your format supports mixed case and non-ascii passwords, the dummy
format should also support mixed case passwords and non-ascii characters.
These format properties are reported in the format details as well.
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.
