[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Nov 2012 16:56:29 -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 reply, very appreciated.
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?
>
> 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 :)
>
> > 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.
Also, if someone have any similar script working and want to share I will
be tankful.
Thanks.
Best regards.
>
> 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.
