|
Message-ID: <20100208071617.GA12936@openwall.com> 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.