|
Message-ID: <cb20b09fc922c957617f68ebcb888149@smtp.hushmail.com> Date: Tue, 20 Nov 2012 00:45:43 +0100 From: magnum <john.magnum@...hmail.com> To: john-users@...ts.openwall.com Subject: Re: How does incremental mode works? 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.