Date: Thu, 20 Jan 2011 20:28:53 +0100 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-users@...ts.openwall.com CC: Solar Designer <solar@...nwall.com> Subject: Re: Plain Text/No-op Password Format Solar Designer wrote > Here's an advantage of these two encode-all approaches: > > On Thu, Jan 20, 2011 at 01:23:30AM +0300, Solar Designer wrote: >> 1. "$hex$" followed by hex-encoded plaintext password. >> >> 2. "$base64$" (or "$b64$") followed by base64-encoded plaintext password. [...] > With these considerations, maybe #1 is the best choice. May be it's better to use $dummy$ instead of $hex$, or $dummy1$, $dummy2$, $dummyNNN$, if multiple dummy formats might be necessary. (Alternatively, $dummy$1$ ... $dummy$NNN$ could be used.) Furthermore, there should be an additional prefix encoding "properties" of the dummy hash algorithm like: -case sensitive -max. password length -7bit/8bit/unicode(?) -saltless/salted -some additional (reserved/ignored) flags for future use Otherwise: -how are some rules supposed to work/be ignored based on the hash type -how should john know when passwords should be truncated Salted hashes would allow to account for the popularity of cracked passwords. For salted hashes, a dummy salt must be part of the dummy hash. The dummy salt should be of variable length. All characters that occur in the hashes of all known hash formats should be allowed to be part of the dummy hash. (This includes the $ sign.) Then, it is easier to convert a john.pot file into a file containing dummy password hashes - you could just use the original hash as the dummy salt. Even this might be necessary, if not for now, then possibly in the future: -encoding: ascii, iso-latin1, utf-8, utf16 (big/little endian) So, this would result in hashes like $dummy$1$_some_flags_$ascii$dummy_salt$313233343536 or, for "saltless" hashes: $dummy$1$_some_flags_$ascii$$313233343536 If only a few of these "features" are considered important enough for a first version (probably nobody wants the implementation of a dummy hash format to be much more complex than the implementation of a real hash format), a version number might be integrated into the hash. I don't know if --format=dummy:1(,2,3) - to pick a (list of) particular dummy format(s) and --format=dummy - for all dummy hashes have to be supported. (It might be tricky to simultaneously "crack" dummy passwords with different case sensitivity/max. length/other attributes.) The icing on the cake would be a conversion tool which automatically "translates" a john.pot file or a word list into a list of password hashes or into a password file. For a john.pot file, the attributes -max. length -case sensitivity -... of the dummy format could be picked from the attributes of the original hash format. For a word list, there should be sane default attributes with the possibility to specify these attributes on the command line. Hm. I'm afraid the implementation of a dummy hash format *is* more complex than the implementation of a real hash format. Frank
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.