Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Nov 2012 00:45:43 +0100
From: magnum <>
Subject: Re: How does incremental mode works?

On 19 Nov, 2012, at 23:56 , Richard Miles <> wrote:
> On Mon, Nov 19, 2012 at 2:09 PM, magnum <> wrote:
> On 19 Nov, 2012, at 16:39 , Richard Miles <>
>> 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
>>> 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.


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.