[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Feb 2010 10:16:17 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Feedback on the generic crypt(3) patch
On Fri, Feb 05, 2010 at 08:14:40PM +0100, Magnum P. I. wrote:
> FWIW, I've had good "non-intended" use of the generic crypt(3) patch as
For others on the list, you're referring to:
http://www.openwall.com/lists/john-users/2009/11/05/1
> it also enables cracking passwords longer than 15 characters.
You're referring to the limitation of JtR's built-in support for
FreeBSD-style MD5-based hashes. This limitation is related to this
specific hash type: it would be twice slower to compute a hash of this
type of a longer password, even with optimal code, so given the fact
that weak passwords of this length were very rare, it seemed not to be
worth the bother (and the extra code).
Other hash types are not subject to this limitation.
> That length is not that hard to attack when you know a pattern, but plain
> john let me down. This patch made my day, once I realized it should
> work. It performs at 25% of the speed of the optimized version but it's
> still 110% better than nothing :)
Understood. I am glad that you found the patch useful. Thank you for
posting this, which might inspire others for "unintended" uses for the
patch as well.
> So my 2 cents: please incorporate "crypt" in the 'official' or at least
> the 'jumbo patch' versions (even if "incomplete"), and I don't think you
> should ever remove it even if/when you end up supporting this new
> password format. It may happen again...
Actually, I thought of including functionality like this into JtR when I
was working on version 1.5 in 1997-1998. One reason why it didn't get in
was that I'd have to deal with the presence of crypt(3) or lack thereof
and with it being in libc vs. libcrypt during JtR build. This would
complicate "make generic" a bit. For other make targets, I could have
the proper settings hard-coded. Since I seemed to have covered all the
crypt(3) hash types in common use at the time, I just didn't bother to
introduce this. Maybe I'll need to do it now. But, as I have explained,
I can't just apply the patch as-is, as it'd break builds on many systems.
Also, since it can't reliably and quickly autodetect hash types it is
not aware of, and since it "overlaps" with JtR built-in code for some,
perhaps there would need to be extra code elsewhere to only enable this
"format" when it is explicitly requested.
Thanks again,
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.
