[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP8170ADE1365E5680606476FD5F0@phx.gbl>
Date: Tue, 5 Jul 2011 21:39:46 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: Charset options
Hi Maximilian,
some remarks in addition to what JimF already mentioned...
Am 05.07.2011 10:40, schrieb Maximilian Melcher:
> Hi list,
>
> I have a small question: Is it possible to modify a charset like
> rockyou.chr
> to stick to a password policy? E.g. password must be 8 characters long and
> must contain at least 1 letter (all upper or lower), 1 digit and 1 special
> sign ?
>
One general reason not to skip passwords which do not match
the current password policy is that there might be older hashes
which have been created prior to the latest policy changes.
Even if it would be a good idea to skip passwords not matching
the policy, you can't generate a .chr file which will produce
only passwords matching your policy.
The reason is that the .chr file contains trigraph, bigraph, and
single letter frequency information for each password length
and letter position.
Even if you build your .chr file from passwords matching
your policy, like "secret+1" and "s*cret01", john's
incremental mode will very soon generate a password
like "secret01" not matching your policy, because for a
password of length 8, position 7, '0' is a very likely
candidate if the letters at positions 5 an 6 are 'e' and 't'.
You might take care of a password policy with the rules
you apply in wordlist mode.
If your word list just contains words consisting of letters,
you can make sure your mangling rules will generate words
containing at least one special character and one digit.
> 1. I experience a huge performance inpact (~20%).
The huge performance impact suggests you are cracking
saltless hashes, with a very fast password algorithm.
Together with
> 2. John still tells me "Warning: mixed-case charset, but the current hash
> type is case-insensitive; some candidate passwords may be unnecessarily
> tried more than once."
this suggests LM, so JimF is probably right.
For LM hashes, it would be totally wrong to filter password candidates
according to your password policy.
Not just due to the performance impact, but because of how LM works.
Imagine passwords like
!2secret
mysecre7$
LM passwords longer than 7 characters can be cut into two halves
which can (and will) be cracked separately.
That means, for the above-mentioned passwords, john has to try these
"words",
to crack the first and second halves:
!2secre
t
mysecre
7$
or (upper case)
!2SECRE
T
MYSECRE
7$
The file john.pot will contain these cracked halves, you'll have to use
the --show option to see the complete passwords.
When cracking LM hashes, john will cut any password candidate
to length 7 and convert it to upper case.
So, if you filter the input based on your policy, you'll end up with
just the first half of the first password being cracked.
Even if you don't crack LM passwords, similar problems might occur.
You should mention the hash type if you want to get advice
matching your problem.
Best regards
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.
