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.