Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Jun 2018 01:03:16 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Using PBKDF2-HMAC-SHA256

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