john-users - Re: Plain Text/No-op Password Format

Openwall GNU/*/Linux 3.0 - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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