[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060106055843.GA16010@openwall.com>
Date: Fri, 6 Jan 2006 08:58:43 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Suggestion/requests and a few questions...
On Wed, Jan 04, 2006 at 08:33:11PM +0000, Phantom wrote:
> 1) Add another character class command.
> Similar to "s?CY - replace all characters of class C in the word with Y".
>
> But instead replace all characters of one class with all characters of another
> class.
>
> If implemented, would this mean that all combinations are tried for each
> replacement?
>
> (So if a word has more than one instance of the first class, all combinations
> of the second class would be tried for all instaces of the first one)
This does not fit into the way wordlist rules are processed currently.
To implement it would require re-working the wordlist rules support.
Right now, each wordlist rule, when applied to one word (or to a pair of
words - e.g., to someone's first and last name for "single crack" mode)
produces at most one candidate password to try.
It may appear to you that sometimes multiple candidate passwords are
produced for one rule and one input word. In reality, this is the
effect of using the rule preprocessor - which produces multiple rules
from a single line in john.conf.
> I wanted to replace vowels in words with symbols and signs,
> so I made this rule:
> "<9>4/?vs?v[.,:;'\"?!`$%^&*()\-_+=|\\<>\[\]{}#@/~]"
>
> However, I found that only 1 sign is replaced at a time - they are not mixed.
Indeed. The above line is expanded into many rules by the preprocessor.
Each rule only knows of one replacement character.
> Would the above suggested addition solve this "issue"?
Yes, but it's not merely an "addition".
> And is it something you would consider implementing?
Currently, no.
> 2) Possible expantion of the incremental function by building markov chains of
> length 5
> out of guessed password statistics based on john.pot,
> and using these to generate the ("random") strings.
Well, as discussed in here recently, there are many ways to be creative
with how you generate candidate passwords - and some of those give
additional guesses on top of what the cracking modes supported in John
currently manage to do in a reasonable time. However, I do not think
that implementing them all within John is worthwhile.
I do not think that this specific candidate password generator you
propose would be more effective than the current "incremental" mode (on
the contrary, I expect it to be less effective), so even if implemented
it would be something to use in addition to what John does currently.
> A friend of mine started making a tool for this to generate wordlists.
He's welcome to post his results in here (that is, percentages of
passwords cracked with his approach vs. "incremental" in the same amount
of time, etc.)
> 3) An option/switch for logfile creation during -single mode to also output
> username (of the cracked hash) to the logfile.
Actually, usernames (and only the usernames) are already output into the
event log files (.log) that current development versions of John
produce. This works for "single crack" mode, too. The corresponding
cracked passwords may be obtained with "john --show" as usual.
> This could help people gain insight into how single rules actually work
> on different input words and help improve/optimize further rule creation.
Yes, although there are a couple of difficulties with this:
1. As a side-effect of John's use of buffering for candidate passwords
(which is required to use the underlying cryptographic implementations
optimally), it is often not certain which "single crack" mode rule
resulted in which successful guess. I was recently asked on this list
to apply a change to John such that the rule would be logged along with
the guess, to which I replied that implementing that would have a
(minor) performance impact (and explained why this is so).
2. The source information (username, full name, home directory name)
resulting in a successful guess might well come from another user
account or even from multiple user accounts which happen to share the
same salt. In fact, John tends to guess more passwords with "single
crack" when it is run on multiple password files at once than it does
when it is run on the same files individually.
> In replies to other posts here, you mention your TODO-list for 1.7 ....is this
> list to be found anywhere? if so, where?
> If not, can it be made avaiable please?
Sorry, my TODO list for John is not publicly available currently and it
is not in a shape suitable for the public.
I might consider starting to maintain a public TODO list for John later.
Speaking of John 1.7 in particular, there are almost no TODO items left
for this version. I am not planning to add any new features into John
before I put out the 1.7 release. So it's just the usual preparations
for the release that are left.
> Will make it easier for us users NOT to suggest/comment on things others have
> already suggested/commented on without having to remember/look through all
> posts.. :)
Oh, that would require a public list of rejected ideas as well. ;-)
Thanks,
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.
