[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <89d8762a3f7751687232574ef55b262b@smtp.hushmail.com>
Date: Mon, 01 Jun 2015 00:44:28 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Bleeding jumbo now defaults to UTF-8
On 2015-05-31 16:09, Marek Wrzosek wrote:
> Let's summarize what have changed. Before defaulting to UTF-8 in
> john.pot were plain-texts and there was possible to use many encodings
> in one wordlist. Moreover plain-texts were known, but information about
> human-readable form of passwords was gone. After change john can use
> only single-encoding wordlists, stores human-readable passwords in
> john.pot, but plain-texts are gone and one will need to repeat cracking
> passwords using many different target encodings. Just defaulting to
> UTF-8 have solved some issues but have created new ones.
True. How often is the new defaults a problem IRL though? If you audit a
system it will likely have just one encoding and you should have a good
idea which is is.
> Maybe there should be some smart "auto" target encoding, that will check
> password candidates (in UTF-8 only) if there are any two-byte codes and
> if all are from the same alphabet (e.g. Cyrillic) then this password
> would be checked using all possible encoding for those characters (e.g.
> KOI8-R, CP1251 and of course UTF-8). Any other situations (all ASCII or
> many different alphabets in one password) and UTF-8 will be assumed.
> This additional target encoding would be turned-on on demand because
> there will be some performance issues.
Unfortunately this can't be implemented in JtR without intrusive
changes. Also, this problem is almost gone already - most everything is
Unicode nowadays. I can't see much RoI here.
> If for cracking password was used other encoding than UTF-8 (if
> --target-encoding was used) than john will save this information in some
> additional pot file (for backward compatibility reasons) using e.g.
> plain-text or name of encoding. Information about encoding would be
> displayed when -show option was in use.
> It's just a thought. Maybe someone here will have a better idea for
> solving those issues.
I considered similar ideas long ago but again I'm not sure it's worth
the effort. But if we ever revise the pot format for other reasons, we
should add a field with hex representation of the native password.
magnum
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.
