[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP119741FD3F98D5686082622FDF90@phx.gbl>
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.
