[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100422011627.GA2400@openwall.com>
Date: Thu, 22 Apr 2010 05:16:27 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Plaintext Length Limited Password Hashes
On Tue, Apr 20, 2010 at 08:52:38PM -0400, Matt Weir wrote:
> # Some [birth] years...
> l Az"19[7-96-0]" <+ >-
> l Az"20[01]" <+ >-
[...]
> ... I realized that they were for when a user's password was truncated.
Exactly. With truncating hashes, it actually makes sense to try these
special cases before proceeding to try the larger number of combinations
for non-truncated passwords, which JtR also does:
l Az"19[7-9][0-9]" <+
l Az"20[01][0-9]" <+
l Az"19[6-0][9-0]" <+
That's 12 rules for potential truncated passwords followed by 120 rules
for non-truncated ones.
> I have two questions then:
> 1) What other password hashes have a short, (less than 20), maximum length
> for the plaintext password. I know the original crypt(3) DES hash had a
> shorter length, but how often does that still pop up? This falls into
> general curiosity.
The original crypt(3) is still pretty common. Recent versions of
commercial Unix systems still use it by default, even if they also
support alternatives that don't have the length limit. These hashes are
also commonly found in Apache .htpasswd files (the filename is
arbitrary, though), because the htpasswd command creates them by default
(one has to specify a non-default option to use a better hash).
Another example would be crypt16, but it's not common and it's not
supported by JtR. bigcrypt probably does not have a 16 character limit
(at least the algorithm can obviously be generalized for longer
passwords, unlike crypt16's), however JtR currently supports bigcrypt
passwords of up to 16 characters long only, and maybe some systems with
bigcrypt have the same limitation (that's just a guess). Anyhow, for
password cracking bigcrypt's truncation length is 8 characters, because
the halves can be and are being cracked separately (much like it's done
for LM hashes).
So for practical purposes and for JtR specifically it's just LM hashes
(split at 7), the traditional crypt(3) (truncation at 8), and bigcrypt
(split at 8).
I am considering introducing a couple of new rule reject flags such that
rules specifically intended for truncating hashes could be quickly
skipped if the current hash type does not have a low length limit, and
also such that rules that only make sense for non-truncating hashes
(e.g., "delete the 10th character") are quickly skipped if the current
hash type is a truncating one. This is a low-priority item on my JtR
to-do list.
> 2) Would it be useful to include those three digit combos still for other
> password hashes, (where the user didn't have their password truncated)?
Somewhat useful, yes, but those 12 would not be any better than the
remaining 988 then, so it would be unreasonable to try them in this
place of the ruleset (before the more-likely full year numbers, etc.)
If you can afford to test all 3-digit numbers, then you should do it
further down the ruleset, and not treat these 12 any special.
Thank you for asking. I think this discussion may benefit others
working on custom rulesets as well.
Alexander
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.
