[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <06f3d226a48a1d6623907307a5e04cf7@smtp.hushmail.com>
Date: Wed, 17 Apr 2013 11:09:04 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Supporting deprecated format syntax (was: Endianity in input files)
On 17 Apr, 2013, at 10:02 , Alexander Cherepanov <cherepan@...me.ru> wrote:
> On 2013-04-17 10:58, Frank Dittrich wrote:
>> On 04/17/2013 04:00 AM, Alexander Cherepanov wrote:
>>> On 2013-04-17 02:18, Frank Dittrich wrote:
>>>> On 04/16/2013 11:54 PM, Alexander Cherepanov wrote:
>>>>> Mainly I thought about cases where fields inside a hash are separated by
>>>>> a char but lengths are also recorded for some fields. This is redundant,
>>>>> makes valid more complex and doesn't really simplify get_salt and co.
>>>>
>>>> Since we can't easily drop support for the old hash format (except for
>>>> new formats which haven't been released in a previous jumbo version),
>>>> these functions will not get simpler by changing the preferred hash
>>>> representation, at least not in the short run.
>>>
>>> Yeah, if we need to process both formats things get more compicated. If
>>> we just print warning for old formats evering becomes easier:-)
>>
>> We would need to provide a tool which converts existing john.pot entries
>> into the new hash representation, before we can drop support for the
>> older, deprecated hash representation.
>> I remember suggesting such a conversion tool in the past, but apparently
>> the need to convert existing .pot files is "too much complexity for the
>> user", see http://www.openwall.com/lists/john-users/2005/06/23/2
>
> I need to read this thread later but generally it seems hard to maintain good john.pot but easy to extract value from it -- cracked passwords. Roughly speaking --loopback should solve most problems IMHO.
In practice this might be hard to explain to the end user. He/she might have an enormous pot file containing a large number of formats, with original input files scattered in different places (even offline) but still a need for picking any of those old input files and show cracked passwords from it. How would we give that user a simple surefire way of upgrading john.pot once and for all?
>>>> The preferred way of storing a hash also depends on
>>>> -how the system which uses these hashes is storing / reporting them
>>>> -what third party tools adopted john's hash representation / support
>>>> which other representations
>>>
>>> IIUC we talk now about formats which get into john through *2john
>>> programs so there is no natural form for them.
>>
>> OK, but third party tools still need to be considered.
>
> Sure. But this thread has started with the problem that the presentation of some hashes must be changed. In such a situation third-party tools are to be broken anyway.
Not if we still support the old syntax as input and in pot files. It's already done that way in a couple of formats.
> And it seems quite appealing to improve the presentation of hashes while we are breaking third-party stuff and old john.pot files. There could be no other possibility to do it.
Have a look at postgres. It supports a deprecated syntax in input files and pot entries, but will always write new pot entries in the new syntax. This is accomplished with prepare() - all other functions work with the new syntax. Another way to accomplish the same thing is to do the conversion in split() but then we need to have valid() support both syntaxes. The prepare() method gives better separation and is easier to review.
In fact, I'd like you to hard-test this format. Can it break? Does it really do what I just said?
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.
