Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 9 Jun 2018 19:23:17 -0400
From: Chris Bonk <bonk.chris@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Using PBKDF2-HMAC-SHA256

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.

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

Your e-mail address:

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