Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 30 Mar 2012 18:10:09 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Simple John Rules Example

On Thu, Mar 29, 2012 at 10:44:34AM -0500, jmk wrote:
> On Thu, 2012-03-29 at 15:30 +0400, Solar Designer wrote:
> > %4?v Dp %3?v D[p*] %2?v D[p*] /?v D[p*]
> > %3?v Dp %2?v D[p*] /?v D[p*]
> > %2?v Dp /?v D[p*]
> > /?v Dp
...

> - Am I correct to assume the "*" in "[p*]" works as a toggle, causing
> the rule to produce candidate passwords with both the character at that
> position and it removed?

Sort of, but for better understanding you need to distinguish rules
(after preprocessing or otherwise containing no preprocessor commands)
vs. ruleset lines (potentially containing preprocessor commands - those
square brackets).  "[p*]" found on a ruleset line results in the
preprocessor producing two rules (or two sets of rules if there are
other preprocessor commands on the line as well): one with "p" in that
place and the other with "*".  "Dp" deletes the character at position
"p", whereas "D*" is a no-op.  (It may be slightly cleaner to use "Dz"
for the purpose.  [List.Rules:NT] uses "z" now.  I forgot about that.)

For example, the line:

%4?v Dp %3?v D[p*] %2?v D[p*] /?v D[p*]

expands into 8 rules.  The entire ruleset quoted above expands into
8+4+2+1 = 15 rules.

> - I'm assuming the rules are processed left to right, correct?

Preprocessor's square brackets are processed right to left, rule
commands are processed left to right.

> With the
> rule "%2?v Dp /?v D[p*]" and the input word of "boat", the whole word is
> processed by the first part of the rule. After that, the second part of
> the rule is looking at just "at".

No.  This is a ruleset line that corresponds to two rules:

%2?v Dp /?v Dp
%2?v Dp /?v D*

These can be optimized to:

%2?v Dp /?v Dp
%2?v Dp

(unfortunately, John does not perform this optimization currently).

The first one of these starts by finding and removing the second vowel
and then does the same for the first vowel.  (I chose to do it in this
order such that words with fewer than two vowels are rejected quicker.)
It always operates on the entire input word - well, with just one vowel
removed when it gets to the second part of the rule.

The second one of these removes the second vowel only.  (We have another
rule to remove the first vowel only.)

> - If I wanted to add "y" in as a vowel, it appears it is not as simple
> as just replacing "?v" with "[aeiouy]". Is that correct?

Yes, it's not that simple.  "[aeiouy]" would produce 6 separate rules
(or even sets of rules).  magnum has already explained how to do what
you want with jumbo.

> - Does the order of rules matter? I see you went from 4 vowel words down
> to 1. Would the reverse order be any different?

The corresponding candidate passwords would be produced in the reverse
order then.  Other than that, there's no difference.

> - I'm playing with expanding these rules to capitalize the first letter
> and append digits/symbols. If I have 7 different append rules (1-4
> digits, 1-3 digits + 1 symbol), I'm looking at 28 total rules (4 vowel x
> 7 append), right?

Perhaps.  (Assuming that by "rules" you refer to ruleset lines here, not
to individual rules after preprocessor, which you'll have thousands of.)

> For example:
> 
> ...
> %3?v [c] Dp %2?v D[p*] /?v D[p*] Azq[0-9][0-9][!$@...^&()_+\-={}|[\]\
> \;'":,/<>?`~*]q <+
> %3?v [c] Dp %2?v D[p*] /?v D[p*] Azq[0-9][0-9][0-9][!$@...^&()_
> +\-={}|[\]\\;'":,/<>?`~*]q <+
> ...
> %2?v [c] Dp /?v D[p*] Azq[0-9]q <+
> %2?v [c] Dp /?v D[p*] Azq[0-9][0-9]q <+

Yes, you can do things like that.  BTW, to append just one character
like you do here:

%2?v [c] Dp /?v D[p*] Azq[0-9]q <+

it may be slightly quicker to use the "$" commands, like this:

%2?v c Dp /?v D[p*] <* $[0-9]

I also removed the unneeded brackets around "[c]" (they would make
sense if you put more commands in there - e.g., for "[lc]") and moved
the length check to be performed earlier (so if a candidate password is
to be rejected for that reason, this will happen quicker).

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ