[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 10 Jun 2018 01:40:03 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Using PBKDF2-HMAC-SHA256
On 2018-06-10 01:23, Chris Bonk wrote:
> Hey Magnum
>
> Thanks for the reply.
>
> The key for this hash is
>
> "governor washout beak"
>
> I tried with the hash file you built but it did not match.
>
> I would assume that trimming to exactly 43 characters would cause an issue.
I'm not sure what the format (as written) is supposed to eat and how it
could ever be 43 bytes. Indeed it seems fundamentally b0rken: A safer
way to only give the first limb of the hash is this:
$ cut -c1-32 <<<
5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273 |
base64 | sed 's/+/./g;s/=//g'
NWYzN2EzYmQwOGFjMWM3ZDE2MzI5NGEzY2IxOTJlZDEK
That's valid data for sure, but it's 44 bytes and that hash doesn't load
- I have no idea why. I believe JimF wrote the current incarnation of
the format.
magnum
>
> Any other options here?
>
> CB
>
> On Sat, 9 Jun 2018 at 19:03 magnum <john.magnum@...hmail.com> wrote:
>
>> On 2018-06-09 21:56, Chris Bonk wrote:
>>> Hello,
>>>
>>>
>>> I'm trying to get PBKDF2-HMAC-SHA256 hashes to be loaded. The example
>> hash
>>> below loads just fine.
>>>
>>>
>> $pbkdf2-sha256$12000$2NtbSwkhRChF6D3nvJfSGg$OEWLc4keep8Vx3S/WnXgsfalb9q0RQdS1s05LfalSG4
>>>
>>> However, my hash below does not. I encoded the salt and digest with
>> base64.
>>> The raw data for simplicity:
>>>
>>> rounds: 100000
>>> "salt": "e65814e4382759f85550029e723dc7e7",
>>> "derived":
>>> "5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273"
>>>
>>> My hash file:
>>>
>> $pbkdf2-sha256$100000$ZTY1ODE0ZTQzODI3NTlmODU1NTAwMjllNzIzZGM3ZTc=$NWYzN2EzYmQwOGFjMWM3ZDE2MzI5NGEzY2IxOTJlZDE0MDdiNjJiYmM2YTYyNTlmZWU1NWY2ZTUzZjc1NDI3Mw==
>>>
>>> This is simply a test hash, I have the key. I just want to ensure that
>> JTR
>>> can properly work with the hashes before attempting to find keys for
>> hashes
>>> I do not know.
>>
>> This particular format of ours sucks, I'm not sure why nor who wrote it.
>> First, it's not MIME Base64 but you need to replace all '+' to '.' (in
>> this case that did not apply, perhaps you were just lucky). Second, I
>> think you have to drop any '=' padding.
>>
>> Example:
>> $ base64 <<< e65814e4382759f85550029e723dc7e7 | sed 's/+/./g;s/=//g'
>> ZTY1ODE0ZTQzODI3NTlmODU1NTAwMjllNzIzZGM3ZTcK
>>
>> Second, the hash (the last base64-string) need to be exactly 43
>> characters long. At least some of the other PBKDF2 formats handle this
>> much smarter, it uses the rest but with early rejection. But I digress -
>> here's how to encode the seconds hex blob:
>>
>> $ base64 <<<
>> 5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273 | sed
>> 's/+/./g;s/=//g' | cut -c1-43
>> NWYzN2EzYmQwOGFjMWM3ZDE2MzI5NGEzY2IxOTJlZDE
>>
>> The complete line:
>>
>> $pbkdf2-sha256$100000$ZTY1ODE0ZTQzODI3NTlmODU1NTAwMjllNzIzZGM3ZTcK$NWYzN2EzYmQwOGFjMWM3ZDE2MzI5NGEzY2IxOTJlZDE
>>
>> As far as I know this one should work fine, but as you didn't supply the
>> correct password for your test hash I can't verify that.
>>
>> What we should do is:
>> 1. Allow this "modified" Base64 *as well as* normal Base64, with normal
>> charset or not, and with padding or not.
>> 2. Allow longer binaries but only do the first limb in the inner loop
>> and check the last/rest in cmp_exact() with some warning on mismatch
>> like I think is done in pbkdf2-hmac-md5 format (or some other, I can't
>> recall which).
>>
>>
>>> Any help?
>>>
>>> Running on Win 7. John the Ripper password cracker, version
>>> 1.8.0-jumbo-1_omp [cygwin 32-bit SSSE3-autoconf]
>>
>> For safer/faster results you should also use a fresh bleeding-jumbo
>> version rather than an ancient release.
>>
>> HTH
>> 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.
