john-users - Re: John as a wordlist creator

Openwall wordlists collection for password cracking (20+ languages)
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 1 Jan 2012 10:06:47 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: John as a wordlist creator

On 12/31/2011 03:12 PM, Alex Sicamiotis wrote:
> I downloaded some extra rules that I merged in john.conf, and while they increased the cracking efficiency,
>
> a) they were very time consuming (it's to be expected)
> b) they had significant overlap due to mangled worlds appearing the same
>
> for example
>
> guesses: 2  time: 0:00:21:43 7%  c/s: 7991K  trying: Alex2194 - Alekshs2
> guesses: 2  time: 0:00:22:48 7%  c/s: 8006K  trying: Giannis2 - Giannhs2
> guesses: 2  time: 0:00:23:17 7%  c/s: 8008K  trying: Alex2521 - Alekshs2
>
> Alekshs2 appeared a few hundred times, and that means it has been tried a few million times :P


This is caused by the hash type being limited to password length 8, and 
the rules you used were not taking this into account.

I guess the rules appended 4 digits (possibly after capitalizing the word).

So, from the input word "giannis" or "Giannis" , the password candidate 
"Giannis2194" has been created. But later on, john did cut the password 
candidate to length 8.

Unfortunately, you didn't mention the rules you used.

To convert "Giannis" into "Giannis2194", the rule could have been

$2$1$9$4
or
Az"2194"
or
Azx2194x
or something similar like
<-$2$1$9$4

To avoid generating passwords that exceed the maximum password length 
for you4 hash type, you could change the rule to

$2$1$9$4<+
or
Az"2194"<+

Then, the password candidate generated from the  input "Giannis"would 
have been skipped, because the resulting password would be too long.

Possibly, your rule(s) appended all possible 4-digit combinations, like 
this:

$[120-9]$[0-9]$[0-9]$[0-9]
or
Az"[120-9][0-9][0-9][0-9]"

In this case, appending "<+" would be less effective, because john would 
generate 10000 password candidates, and reject all of them.

In this case, adjusting the rules to

<-Az"[120-9][0-9]<-Az"[0-9][0-9]"

or something similar would be better.
This rule (or, rather, these 10000 rules) reject(s) input words unless 
their length is shorter than (max. length - 1), then 2 digits are 
appended, then the result is rejected if unless the length is shorter 
than (max. length - 1), then 2 more digits are appended.

If you know you want to use these rules only for hash types with 
password length 8, you could even use

<5Az"[120-9][0-9][0-9][0-9]"

Of course, skipping rules when the resulting password candidate would 
have been too long usually only makes sense when you tried rules 
appending shorter sequences of digits first.

So, with more sophisticated rules you can reduce the risk of producing 
duplicate password candidates.
(You can not avoid duplicates, because this also depends on your input 
word list. IF you have a rule which replaces all vowels with '*', 
different input words can be converted into the same password candidate.)

Regards,
Frank