Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110119222330.GA24353@openwall.com>
Date: Thu, 20 Jan 2011 01:23:30 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Plain Text/No-op Password Format

On Wed, Jan 19, 2011 at 09:08:59PM +0000, Freddie Witherden wrote:
> I am interested to know if John supports (or there exist patches to add
> support) for a plain text password format.  That is to say one in which
> the password itself is known in which the cipher-text is the same as the
> plain-text.

No, but this is on my to-do for JtR.  The ciphertext should not always
be exactly the same, though, or we would not support passwords with
colons in them.  Here are some options for us to choose from (or several
of these may be supported at once):

1. "$hex$" followed by hex-encoded plaintext password.

2. "$base64$" (or "$b64$") followed by base64-encoded plaintext password.

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.

Please vote on these or/and make other suggestions.

> My interest in such a format is in answering questions such as "with a
> given set of rules/word lists how many candidates would have to be
> generated to determine the password."

Right.  Another reason to implement this is to be able to benchmark
the "high-level" code in JtR separately from any password hashing.

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.