|
Message-ID: <36cb09a32bb0c97d3f72d16f429e5dd5@smtp.hushmail.com> Date: Wed, 23 Jan 2013 23:43:20 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: External mode filter vs max length (was: Min password length) On 23 Jan, 2013, at 18:52 , magnum <john.magnum@...hmail.com> wrote: > On 23 Jan, 2013, at 18:43 , Frank Dittrich <frank_dittrich@...mail.com> wrote: >> I knew how --min-length=N and --max-length=N work for --incremental and >> --markov (tested this in the past). >> After my last reply to Jim I tested it with --wordlist (with and without >> --rules), and was just thinking about how to test it for --single mode >> (since --single doesn't work well with --stdout). >> >> What happens (what is the expected behaviour) if --single or --wordlist >> is combined with an --external filter? > > That is a jolly good question. The figures are available as new external mode variables (req_minlen and req_maxlen). But I'm afraid the rules engine (or Wordlist's dummy_rules) will drop a word even though an external mode would make it comply. We need to review this. I tried this: $ cat ../run/john.local.conf [List.External:Every_other] void filter() { int i, c; i = 1; while (c = word[2*i]) word[i++] = c; word[i] = 0; } $ echo hellofolks | ../run/john --stdin --stdout --ext:every_other hlook $ echo hellofolks | ../run/john --stdin --stdout=6 --ext:every_other hlo words: 1 time: 0:00:00:00 w/s: 14.28 current: hlo Oops. First, it's truncated to "hellof" and then, the filter picks every other character from that. If we enforced the limits later, the result would have been "hlook" again because it's shorter than 6. This is how John behaves regardless of --min/max-length. Even core john does this, although it doesn't have the length parameter of --stdout (but the same will happen for a format with a max length of 6). The limit is enforced before the external filter is applied, while arguably it should be enforced after it. $ echo hellofolks | ../run/john --stdin --stdout --max-len=6 --ext:every_other words: 0 time: 0:00:00:00 w/s: 0.00 Using --max-length instead, it gets rejected completely, by the same logic. So there is room for improvement here, but it is specific to the new options but External mode filters in general. We could do something like this: 1. All places that currently check for min/max lengths should refrain from doing so if an external filter is used. 2. The external mode (not the john.conf stuff, but external.c) should enforce the limits to the *final* candidate. This might be a desirable improvement to core as well. However, we must consider if the current behaviour is preferable in some cases? I'm not quite sure. 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.