[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFMma9M5n7aQGnQbD_0f+5TAp9mRjrymetLBOroka95Hhx1AeQ@mail.gmail.com>
Date: Wed, 21 Nov 2012 10:41:08 -0600
From: Richard Miles <richard.k.miles@...glemail.com>
To: john-users@...ts.openwall.com
Subject: Re: How does incremental mode works?
Hi Magnum,
Thanks for your answer very appreciated.
Based on Frank's message I think that Markov is not what I'm looking for to
automate the creation of candidates hashes based in a password policy.
However, I believe it may be done with incremental mode, right?
Do you have any reference or example of these policy filter or equivalent
solutions being used to generate such kind of specific candidate passwords
for jTr running with incremental mode?
Thanks.
On Mon, Nov 19, 2012 at 5:45 PM, magnum <john.magnum@...hmail.com> wrote:
> On 19 Nov, 2012, at 23:56 , Richard Miles <richard.k.miles@...glemail.com>
> wrote:
> > On Mon, Nov 19, 2012 at 2:09 PM, magnum <john.magnum@...hmail.com>
> wrote:
> > On 19 Nov, 2012, at 16:39 , Richard Miles <
> richard.k.miles@...glemail.com>
> >> wrote:
> >>> B.1) Once a new password is cracked with Markov should not be useful to
> >> get this information to update the stats file and recalculate the
> >> probabilistic? It may be wrong, but I guess that for example with a good
> >> amount of passwords cracked with Markov if we used this data to modify
> the
> >> stats "on the fly" it could give better results, not?
> >>
> >> You will never have a perfect stats file. Given that, your suggestion
> will
> >> amplify the errors instead of making things better: Let's say your stats
> >> file have too much weight for the letter 's' so you crack a lot of
> password
> >> containing 's'. While this is a good thing, the downside is you missed
> (for
> >> the sake of example) nearly all passwords containing a 'q'. Now, if you
> use
> >> these results to modify your stats file, you get even more weight to 's'
> >> and even less weight to 'q'.
> >>
> >
> > Humm.. this makes sense. This idea of weight for chars looks similar to
> me
> > to word frequency. Isn't it the principle for incremental mode?
>
> My description of the "scenario" was a lot simplified (and in fact generic
> - it applies to any way of producing candidates unless you exhaust the
> keyspace). I just randomly chose the word "weight" while in fact it might
> be that tri-graph voodoo magic or whatever.
>
> >> This is why the RockYou list is so much better than any list of cracked
> >> passwords. Because the passwords were stored in the clear, the RockYou
> list
> >> is a complete list of passwords from a large user base, not just the
> ones
> >> that were cracked using some sort of method that will (always) have
> more or
> >> less of errors like the (extreme) example I gave above.
> >>
> >
> > Cool, this makes a lot of sense. But on the other hand since there was no
> > password policy enforcement this may not be good for such situations. At
> > least it's what I learned until the moment :)
>
> One way to attack that is running the RockYou list through a policy filter
> (be it John's external filter, a perlscript or just good ol' grep) and
> produce a subset that only contains passwords that pass your policy. Then
> create a stats file (or a charset file for incremental mode) from that.
> While this is not as good as if RockYou would have that policy in place, I
> bet it will be excellent.
>
> >>> D.1) This one is for Magnum again since he always improve jTr with
> >> amazing small features that make our files easier. Today calculate the
> time
> >> that Markov will run based on time is a bit of pain as described here
> >> http://openwall.info/wiki/john/markov
> >>>
> >>> Do you think that you could add a new command-line option to automate
> >> it? For example, maybe we could do something like
> >> --markov=autoadjust-10800:0:0:13 whre jTr would calculate itself the
> best
> >> possibility of markov level based on the current password cracking
> speed of
> >> the target hash and autoadjust it to run during 3 hours (10800). What do
> >> you think?
> >>
> >> That would be nice, but I currently don't have time and inspiration to
> do
> >> anything like that. Doing it inside JtR itself might be a lot more
> tricky
> >> than it might seem. It's probably a lot easier to make a trivial script
> >> that accomplishes what you want.
> >>
> >
> > Sorry, I was not aware it was tricky. I will try to do an script or
> > something like that.
>
> I'm not sure it's that tricky, I just guess it is. And I do like the idea.
> You could always add it to the wiki wish-list. Someday, someone might get
> the idea to implement it.
>
> magnum
>
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.
