Date: Sun, 28 Jan 2007 14:47:39 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: how to find a password of 16 digits Frank, I wrote: > >[Incremental:Digits16] > >File = $JOHN/digits16.chr > >MinLen = 16 > >MaxLen = 16 > >CharCount = 10 > > > >Note that this new digits16.chr will also work for lengths 0 to 15, if > >you ever need that. On Sun, Jan 28, 2007 at 11:58:59AM +0100, Frank Dittrich wrote: > Why do you need a new chr file? > Wouldn't the original digits.chr file work as well (or a poorly, > for that matter)? No, it would not work at all. Once you recompile JtR with different CHARSET_* settings, the .chr file format changes. > I didn't recompile JtR for incremental mode with length 16, but your > example looks like John tries 2222222222222222, then all passwords > containing just the digits 2 and 4 (and at least one digit 4), then > all passwords containing at least one digit 0 and only digits 2, 4, > and 0, and so on. That's true. Essentially, the information on what digits are likely to be seen together (or the conditional probabilities) is lost with such a length expansion. > Just assume you want to crack case insensitive passwords of length 8. > There's no suitable .chr file, so you could use: > > [Incremental:lanman8] > File = $JOHN/lanman.chr > MinLen = 8 > MaxLen = 8 > CharCount = 69 Yes, this would work - because you do not need to recompile JtR for it. And, yes, it simulates the same length expansion well. There's no information specific to length 8 within lanman.chr, so JtR has to fallback to using the "global" list of characters ordered for decreasing frequency (such a list is included in all .chr files). > IMO this proves that such statistical information from shorter > passwords is of limited use for longer passwords. I'd say that it proves that this specific approach of length expansion is rather poor. I think that better results would be achieved by placing pairs of 8-digit candidate passwords on each john.pot line (for 16-character "cracked" passwords). > I just want to mention this to emphasize that, without additional > knowledge about the password, you shouldn't hope to find the > correct password easily, no matter what method you use, Indeed. The keyspace is very large, so more information on likely 16-digit passwords is needed. I think that a pool of credit card numbers would work really well to train JtR, if Johnny has that. ;-) If not, then maybe the output of a credit card number generator program (such as THC-Credit) would work fine, too. I don't know if these programs would output lots of numbers to a file (haven't tried downloading them), but I'd expect so. > because the key space of 16 digit passwords is larger than the > key space of DES passwords (up to 8 characters, with CharCount 95). Oh, it's only a little bit larger, so that's not the primary problem. It all depends on how the likely passwords are distributed within that space and what information we have on that distribution. -- 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