Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 Jul 2012 01:36:13 +0400
From: Alexander Cherepanov <cherepan@...me.ru>
To: john-dev@...ts.openwall.com
Subject: Re: mscash2 / hmac-md5 ambiguity

On 2012-07-23 14:59, magnum wrote:
>>>> mscash2 hashes in their canonical form are nevertheless accepted as
>>>> hmac-md5:
>>>>
[skip]
>>>>
>>>> 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". We can stop this by
>>> black-listing certain format salts. That's OK with me but in some way
>>> it's a flawed path.
>>
>> hmac-md5 doesn't have the "split() method unifies case" flag set, but
>> mscash2 has.
>> could we change that in a way that one format uses uppercase, the other
>> lowercase? Or would breaking backwards compatibility hurt too much?
>> If hmac-md5 is less likely to be cracked with john, we could convert
>> that one to upper case hex, and drop the flag from mscash2.
>
> The hmac format should unify case too, it's a to-do (and a bug). IMHO
> the only really good solution is to accept the harmless warning. We get
> very similar warnings in many other situations.

How many such situations are there?

For now I see the following:

canonical       is accepted as

dynamic_23      sapg
mscash2	        hmac-md5
mssql05	        dynamic_19
oracle11	dynamic_0 dynamic_2 dynamic_3 dynamic_19 dynamic_22 dynamic_23 
dynamic_26 dynamic_29 dynamic_30 dynamic_33 dynamic_34 dynamic_50 
dynamic_1001 dynamic_1002 dynamic_1003 dynamic_1004 dynamic_1005 
dynamic_1006 dynamic_1010
phpass	        dynamic_17
phps	        dynamic_6
raw-md5	        dynamic_0
raw-sha1	raw-sha1 raw-sha1-linkedin sapg raw-sha1-ng dynamic_26

-- 
Alexander Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ