[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200411102239.GA6400@openwall.com>
Date: Sat, 11 Apr 2020 12:22:39 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Can incremental mode be started in the middle?
On Fri, Apr 10, 2020 at 04:59:36PM -0500, Kevin Yochum wrote:
> I'm experimenting with cracking a hash with a password that is known to be
> an apparently random mix of upper ASCII, lower ASCII, and digits.
If it's in fact random and with a uniform distribution, then e.g. an
all-lowercase password is just as likely as any other.
> When I
> start up a default incremental:Alnum session, it appears as though JtR
> wants to start with the lower case alpha options, even English
> approximations, first with a sprinkling of digits at the end only.
>
> Is this Markov mode, even though I'm not telling JtR to use Markov on the
> command line?
It's not the same as what's called "Markov mode" in JtR. They're two
distinct modes. However, they're similar in concept.
> While these are possible solutions, for my test case, it is highly unlikely
> that starting with all lower case will be the fastest solution.
What makes you think so?
You might be thinking that if the password is a "random mix of upper
ASCII, lower ASCII, and digits", then it's unlikely that it's all lower
case. For random passwords from that possible password space, assuming
a uniform distribution, that is in fact true. However, it does _not_
follow that "it is highly unlikely that starting with all lower case
will be the fastest solution." You need to consider not how likely it
is that the password is of a particular pattern, but how likely each
candidate password within that pattern is to be the one, as compared to
the likelihood of each candidate password of another pattern being the
one. For a uniform distribution, these probabilities are the same.
Moreover, if there's even the slightest chance that the password is not
uniformly random, but is from a distribution skewed even very slightly
towards what was seen in other passwords before, then incremental mode's
strategy is preferable.
In other words, incremental mode's strategy generally does not hurt, and
might help.
However, you did not mention your hash type. If it's a fast hash (where
you're computing millions of hashes per second) and you're reasonably
confident that incremental mode's strategy isn't helpful in your case,
then you might want to switch to mask mode, which might be quicker at
generating candidate passwords (and for fast hashes is able to do so on
device side, such as on a GPU). You'll need to compare the p/s rates.
> Rather than
> start here, I'd like to start with a more random mix of upper and lower
> ASCII and digits, then try all-lower options later, if needed. Is there any
> way to tell JtR to start in the middle and work outward to the ends, or
> something similar?
Officially, no. Unofficially, you may edit the .rec file. I recommend
that you don't.
If you insist, you may try mask mode and include e.g. an uppercase
letter somewhere in your mask, then move it to another position, etc.
My opinion, though, is that this de-optimization is pointless, as I
tried to explain above.
For very slow hashes, you may also try combining incremental mode with
an external filter - see the default "[List.External:Policy]" example.
You can first run with the policy enforced, then with the policy
inverted (anti-policy enforced). Again, based on your description, I
find this pointless, and a waste both of your time and of CPU time.
Such policy enforcement would potentially make sense if you reasonably
expect that a similar policy was also enforced when the password was
generated or when it was set (that is, the password is _not_ entirely
random, but e.g. is random with restrictions). However, even in that
special case the point is moot, see:
https://openwall.info/wiki/john/policy
Alexander
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.
