[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8976fdde47e7bfeda6c98ddac0e56e86@smtp.hushmail.com>
Date: Tue, 07 Jan 2014 11:45:52 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Accepting multiple format tags as valid
On 2014-01-07 11:27, Frank Dittrich wrote:
> On 01/07/2014 11:14 AM, magnum wrote:
>> On 2014-01-07 09:43, Frank Dittrich wrote:
>>> Format dynamic_33 could also accept $NT$ hashes.
>>> Currently, it only recognizes the plain hex hashes without any prefix.
>>> But NT hashes and dynamic_33 hashes only differ in their prefix.
>>>
>>> In this case, it might even be good if dynamic_33 would use $NT$ as the
>>> default prefix.
>>> Also, all the implementations (dynamic_33, nt, nt2) support the same
>>> max. password length of 27.
>>>
>>> At least accepting $NT$ as valid would be an improvement.
>>
>> I think it should simply be one single but *configurable* tag. If
>> nothing is configured, dynamic_1000 will have $dynamic_1000$ but if it's
>> configured as $foo$, that and only that tag is valid, and is written to
>> pot. Constraint on configured tag is that it start and ends with $
>
> 1. If we drop $dynamic_33$ as valid, then hashes stored in an older pot
> file will be ignored, because these will use $dynamic_33$.
Once we do this we will cease producing this situation so it will be a
one-time problem. We document it and people can s/this/that/ if they
want to.
> 2. As long as this doesn't lead to a dynamic format grabbing hashes it
> can't crack, I wouldn't use any restrictions regarding a possible prefix.
Agreed for sure, but it might be more problematic to implement.
>> On a related note I've had thoughts about core *) functionality for tag
>> aliasing. A list of tags will be accepted, but converted to a canonical
>> tag at loader stage with no particular support from the format. The
>> canonical (the format's) tag will be written to pot so in that end no
>> logic is needed.
>>
>> Speaking of that I've also considered some kind of format name aliasing.
>> That way when we change the name of a format, the old name can still be
>> used. It will be converted during options parsing, so format will know
>> nothing about it. You would love writing bash completion for that %-)
>>
>> Both these will have their lists in john.conf.
>
> Will you post your design ideas/decisions to john-dev first, or will we
> find out once the change hits bleeding-jumbo?
I'm not sure it will ever be implemented. Sometimes we do too much of
this kind of stuff and too little fast formats that cracks hashes.
Having said that, sure I can discuss it here first. There have been long
periods where I (and you) didn't get a single comment on lots of ideas
and when that happens I tend to communicate less and less.
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.
