Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 Jul 2012 01:57:10 +0200
From: magnum <>
Subject: Re: mscash2 / hmac-md5 ambiguity

On 2012-07-23 23:19, Alexander Cherepanov wrote:
> On 2012-07-23 14:46, magnum wrote:
>> On 2012-07-23 11:47, Alexander Cherepanov wrote:
>>> mscash2 hashes in their canonical form are nevertheless accepted as
>>> hmac-md5:
>>> $ cat mscash2.john
>>> chatelain:$DCC2$10240#chatelain#e4e15fdfafc8e715da9edec3611bfbff
>>> $ john mscash2.john
>>> Warning: detected hash type "mscash2", but the string is also recognized
>>> as "hmac-md5"
>>> Use the "--format=hmac-md5" option to force loading these as that type
>>> instead
>>> Loaded 1 password hash (M$ Cache Hash 2 (DCC2) PBKDF2-HMAC-SHA-1
>>> [128/128 SSE2 intrinsics 8x])
>>> guesses: 0  time: 0:00:00:02 0.00% (2)  c/s: 339  trying: 123456 -
>>> abc123
>>> Session aborted
>>> $ john --format=hmac-md5 mscash2.john
>>> Loaded 1 password hash (HMAC MD5 [128/128 SSE2 intrinsics 12x])
>>> guesses: 0  time: 0:00:00:02 0.00% (3)  c/s: 1120K  trying: 123man -
>>> 123mah
>>> Session aborted
>>> IMHO that's not very good.
>> It was much worse until we forced hmac-md5 to lower precedence than
>> mscash. Now it is just cosmetic. That hash *is* a valid hmac-md5 hash,
>> with a salt of "$DCC2$10240#chatelain".
> Were these forms chosen for compatibility with other tools? I mean it's
> a pity to have a special, canonical form for a hash which clashes with
> other formats.

It does not really clash, it just warns. It picks mscash2, emits the
notice and all is fine. Is it that bad? I loved when core got this feature.

>> We can stop this by
>> black-listing certain format salts. That's OK with me but in some way
>> it's a flawed path.
> Agreed.

Just thinking out loud here: Let's say we could teach the hmac-MD5
format that "it" should not emit that warning if the salt starts with
$DCC2$10240# - as opposed to always reject it in valid(). In the
(unlikely) case this was really a hmac salt, we could still use the hmac
format using --format. If we don't, it will pick mscash2 and not
complain. The only problem with this approach is it's not supported by
the current core and I'm not sure how we could implement that... or...
perhaps hmac-md5's valid() could take a peek at options.format (the
--format argument) and behave differently if unset... maybe this is
possible. I might try that some time.


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.