[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Jul 2012 02:42:42 +0400
From: Alexander Cherepanov <cherepan@...me.ru>
To: john-dev@...ts.openwall.com
Subject: Re: mscash2 / hmac-md5 ambiguity
On 2012-07-24 02:41, jfoug wrote:
>> From: Alexander Cherepanov [mailto:cherepan@...me.ru]
>> But, as Frank pointed out, it's better if --format is not required --
>> less chances that a user will forget it. Probably we can ignore it until
>> we actually meet hmac-md5.
>
> That's easy. Simply use core JtR with only 5 or 10 possible formats, never
> try to crack anything beyond that, and you will have no problems at all ;)
>
> I think we are now pushing over 120 formats, written by different people.
> Numerous of these formats handle data in multiple ways, and/or
> handle/convert raw hash strings as valid data. That is where ambiguity
> creeps in. There is absolutely no way around the ambiguity. It simply is
> not going to happen, unless we force a unique string for each format, and
> that will force users to have to modify the 'native' hash strings they have
> in hand, just to fit into JtR.
>
> It is pretty hard (impossible) to go with no -format, if presented with 32
> byte hex strings. It could be 1 of millions of different types hashes. Or
> what would be a 40 byte hex string. Again, same issue.
>
> The first (32 byte hex) could be:
>
> md5($s.$p)
> md5($p)
> md5(md5($p))
> md5(sha512($p).$s)
> md4(sha512($p).$s)
> chop_low_16_bytes(sha512($p))
>
> etc, etc.
>
> If that is what is native ITW, but none of them are compatible with each
> other, then it is up to the user running JtR to specify what method was
> used, and of course, JtR would have to support the hash.
You are talking about formats found ITW but
$DCC2$10240#chatelain#e4e15fdfafc8e715da9edec3611bfbff is internal
format of john and could be chosen so as to avoid collisions.
IIUC hmac-md5 is also found ITW as two separate parts not concatenated
with the number sign.
So the question is not whether we can do without --format with a given
files. Rather it's whether we can convert given files to a form which
permit omitting --format. And we almost there: --show=left do it. But
not quite as it turns out.
> It is a good goal to try to remove some of these issue, and CERTAINLY to
> have the 'default' representation be the most often seen ITW. I currently
> think we have the wrong 32 byte hex 'default'. It picks LM. That is due to
> it being LM in the core JtR. But in the wild is NTLM
Isn't NTLM usually found in pwdump format (i.e. in other field than
other types of hashes)?
> or raw-md5 more likely
> to be seen, for 32 byte raw hex? I think so, but right now JtR defaults to
> LM.
>
> Sorry, I will hop off the soapbox now.
--
Alexander Cherepanov
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.
