[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110119231457.GA24905@openwall.com>
Date: Thu, 20 Jan 2011 02:14:57 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Plain Text/No-op Password Format
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.
over the maybe-partial escaping/encoding approaches:
> 3. "$plain$" followed by plaintext password with any colons escaped as
> "\c" and any backslashes escaped as "\\". Maybe also support "\n" and
> "\r" escapes for LF/CR chars embedded in passwords.
> 4. URL-like %-encoding. That is, always encode chars that need encoding
> (only the percent and the colon characters), but optionally encode any
> other characters as well. Maybe this brings us the best of both worlds
> because it lets us use either the substitution approach (just substitute
> the two "bad" characters) or the encode-all approach. It also allows
> for embedded and encoded linefeeds and terminal control characters. The
> prefix could be "$plain$" or maybe "$percent$" or even "$%$".
The advantage of the first two is that they allow JtR to trim and ignore
any whitespace characters before/after the "ciphertexts" or to refuse to
load such ciphertexts, whereas with #3 and #4 such whitespace, if it
inadvertently gets into an input file, will affect/distort the results.
With real hashes, JtR will currently refuse to load hashes with
whitespace before or/and after them, and a future version might ignore
such whitespace in some cases (in the one hash per line input file
format, with no colons, which is supported starting with 1.7.6). Having
an escaping/encoding type that is sensitive to surrounding whitespace
would be inconsistent with this.
As an option, #4 could be revised to require %-encoding of any
whitespace characters at the beginning and/or at the end of a password,
but this makes its definition complicated.
With these considerations, maybe #1 is the best choice.
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.
