[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2976c6b28871ce8c89624db270d7ac71@smtp.hushmail.com>
Date: Thu, 12 Apr 2012 11:03:52 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: MSCash2 formats reliability & usability
On 04/12/2012 12:17 AM, Solar Designer wrote:
> Jim, magnum, Lukas, Sayantan -
>
> We have three JtR formats for MSCash2: CPU, CUDA, OpenCL.
>
> The CPU one supports many different representations of MSCash2 hashes
> and has many test vectors of different form ($DCC2$ prefix present vs.
> not, iteration count included vs. not, username included vs. separate).
> This is great, although the format's support for variable iteration
> counts is probably unneeded (there are no non-10240 MSCash2 hashes in
> the wild, as far as I'm aware). However, I think with all this
> complexity the format is also more prone to bugs than it has to be.
> For example, with this combination of hashes in the input file:
IMO we should not drop the iteration count support. Any admin can raise
it with a change in the registry, and MS may bump the default at any time.
> $DCC2$Joe#e09b38f84ab0be586b730baf61781e30
> $DCC2$test#a86012faf7d88d1fc037a69764a92cac
> $DCC2$administrator#a150f71752b5d605ef0b2a1e98945611
> $DCC2$administrator#c14eb8279e4233ec14e9d393637b65e2
> $DCC2$administrator#8ce9c0279b4e6f226f52d559f9c2c5f3
> $DCC2$administrator#2fc788d09fad7e26a92d12356fa44bdf
> $DCC2$administrator#6aa19842ffea11f0f0c89f8ca8d245bd
>
> John does not recognize the different salts (should be 3 different):
>
> user@...l:~/john/magnum-jumbo/run$ ./john pw-bug -fo=mscash2
> Loaded 7 password hashes with no different salts (M$ Cache Hash 2 (DCC2) [SSE2i 8x])
That's a bug. I or Jim should have a look at this.
> I guess there's a bug in prepare(), get_salt() or/and SALT_SIZE. By
> the way, it is weird how SALT_SIZE is defined as 11*4, but is actually
> put into the struct as SALT_SIZE+4. Assuming that this is the correct
> value to use, we should specify SALT_SIZE as (11*4+4) right away.
Yes, that sounds weird.
> Another issue is that strings of the above form are somehow also
> recognized as "mscash". I guess this has to do with
> mscash1_fmt_plug.c's prepare() being too willing to turn anything into
> what its valid() would recognize. It should probably perform some
> validation first.
This is clearly also a bug. Mscash should at least reject the $DCC2$ tag.
> Yet another issue is that strings of the form something#32hexdigits are
> valid for "hmac-md5", so that's what the above ones are autodetected as.
> Perhaps we want to have mscash and mscash2 (as well as their CUDA and
> OpenCL varieties) checked before hmac-md5. Maybe we should rename
> hmacMD5_fmt_plug.c into non-plug and register it explicitly after other
> stuff. For consistency, maybe we should do it for hmacSHA1_fmt_plug.c
> as well. SHA-2 based HMACs are already non-plugins for another reason.
I'll have a look at this.
> Finally, as it relates to the CUDA and OpenCL formats for mscash2, these
> recognize only a subset of inputs that the CPU mscash2 format does.
> Can we please bring the three in sync, including maybe by dropping
> support for weird inputs (not actually used by anyone) in the CPU format?
>
> BTW, the CUDA and OpenCL formats do not have the salts bug
Unless there are specific reasons, prepare(), valid(), get_salt() and
several other functions could/should be identical between the GPU and
non-GPU formats (once bugs are gone), and then they will behave the
same. At that point I think all three should use the same set of test
vectors too.
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.
