Date: Tue, 4 Mar 2008 09:31:31 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Password to guess with a lot of information On Mon, Mar 03, 2008 at 02:13:43PM +0100, L B wrote: > - the password is 9 letters long > - the password has 7 letters alphanum and 2 digit at the end > > I modified params.h to support 9 characters and recompiled john. > > I defined a new "profile" in john.conf : > [Incremental:myinc] > File = /tmp/john/run/alnum.chr > MinLen = 9 > MaxLen = 9 > CharCount = 36 > > I wanted to use the alnum.chr charset but it doesn't look valid anymore to > john (because of the 9 digits stuff ?) : Incompatible charset file: > /tmp/john/alnum.chr Correct. You need to generate a new .chr file after the recompile. > I tried to --make-charset but I don't understand which kind of source files > it wants (I just want alpha+num!) It does not require any input files other than your john.pot. If you do not already have a large number of cracked passwords in your john.pot (preferably of length 9), then you may use a fake john.pot based on a wordlist to generate your .chr file. You may also reuse some information from an existing .chr file by having JtR generate many candidate passwords based on the .chr file and saving them into the fake john.pot (this won't work very well in your specific case because none of the .chr files supplied with JtR will produce 9-character strings). Some examples of these approaches can be found on these older postings: http://www.openwall.com/lists/john-users/2007/07/04/6 http://www.openwall.com/lists/john-users/2007/01/28/1 http://www.openwall.com/lists/john-users/2006/09/09/2 http://www.openwall.com/lists/john-users/2005/05/15/4 > How can I do to find this password ? By defining rules ? Probably not. Use a custom "incremental" mode and/or an external mode. Yes, it may make sense to use a combination of both modes, in one of two ways: 1. Define a 9-character alpha-numeric "incremental" mode (requires a JtR recompile and a custom .chr file). Define an external filter() that will only let candidate passwords ending in two digits pass. That is, when the "word" is unsuitable, set "word = 0". Use both modes at once. 2. Define and use "incremental" for the first 7 characters (does not require a recompile, nor a custom .chr file). Define and use an external filter() that will modify "word" by adding two digits to it. You'd have to do up to 100 invocations of JtR with different filter() functions - separately for each two-digit combination. Obviously, the second way is much more efficient in terms of the c/s rate. As a bonus, you get a very efficient way to distribute the work across up to 100 CPU cores in any number of machines. For a pure external mode solution, that is not as good as "incremental" mode in terms of the order in which candidate passwords are tried, you may use a variation of the "DumbForce" mode seen on this recent posting: http://www.openwall.com/lists/john-users/2008/02/24/1 You'd need to enhance it to use different character sets for different character positions. > I guess with the information I have it should be quite quick. It is perfectly realistic to crack that password, but I would not expect it to necessarily be very quick. Good luck! -- Alexander Peslyak <solar at openwall.com> GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ