[john-users] Using PBKDF2-HMAC-SHA256

[Chris Bonk]

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.

Any help?

Running on Win 7. John the Ripper password cracker, version
1.8.0-jumbo-1_omp [cygwin 32-bit SSSE3-autoconf]

[magnum]

Post by Chris Bonk
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.
rounds: 100000
"salt": "e65814e4382759f85550029e723dc7e7",
"5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273"
$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).

Post by Chris Bonk
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

[Chris Bonk]

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

Post by Chris Bonk

Post by Chris Bonk
Hello,
I'm trying to get PBKDF2-HMAC-SHA256 hashes to be loaded. The example

hash

Post by Chris Bonk
below loads just fine.

$pbkdf2-sha256$12000$2NtbSwkhRChF6D3nvJfSGg$OEWLc4keep8Vx3S/WnXgsfalb9q0RQdS1s05LfalSG4

Post by Chris Bonk
However, my hash below does not. I encoded the salt and digest with

base64.

Post by Chris Bonk
rounds: 100000
"salt": "e65814e4382759f85550029e723dc7e7",
"5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273"

$pbkdf2-sha256$100000$ZTY1ODE0ZTQzODI3NTlmODU1NTAwMjllNzIzZGM3ZTc=$NWYzN2EzYmQwOGFjMWM3ZDE2MzI5NGEzY2IxOTJlZDE0MDdiNjJiYmM2YTYyNTlmZWU1NWY2ZTUzZjc1NDI3Mw==

Post by Chris Bonk
This is simply a test hash, I have the key. I just want to ensure that

JTR

Post by Chris Bonk
can properly work with the hashes before attempting to find keys for

hashes

Post by Chris Bonk
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.
$ 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 -
$ base64 <<<
5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273 | sed
's/+/./g;s/=//g' | cut -c1-43
NWYzN2EzYmQwOGFjMWM3ZDE2MzI5NGEzY2IxOTJlZDE
$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.
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).

Post by Chris Bonk
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

[magnum]

Post by Chris Bonk
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

Post by Chris Bonk
Any other options here?
CB

Post by Chris Bonk

Post by Chris Bonk
Hello,
I'm trying to get PBKDF2-HMAC-SHA256 hashes to be loaded. The example

hash

Post by Chris Bonk
below loads just fine.

$pbkdf2-sha256$12000$2NtbSwkhRChF6D3nvJfSGg$OEWLc4keep8Vx3S/WnXgsfalb9q0RQdS1s05LfalSG4

Post by Chris Bonk
However, my hash below does not. I encoded the salt and digest with

base64.

Post by Chris Bonk
rounds: 100000
"salt": "e65814e4382759f85550029e723dc7e7",
"5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273"

$pbkdf2-sha256$100000$ZTY1ODE0ZTQzODI3NTlmODU1NTAwMjllNzIzZGM3ZTc=$NWYzN2EzYmQwOGFjMWM3ZDE2MzI5NGEzY2IxOTJlZDE0MDdiNjJiYmM2YTYyNTlmZWU1NWY2ZTUzZjc1NDI3Mw==

Post by Chris Bonk
This is simply a test hash, I have the key. I just want to ensure that

JTR

Post by Chris Bonk
can properly work with the hashes before attempting to find keys for

hashes

Post by Chris Bonk
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.
$ 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 -
$ base64 <<<
5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273 | sed
's/+/./g;s/=//g' | cut -c1-43
NWYzN2EzYmQwOGFjMWM3ZDE2MzI5NGEzY2IxOTJlZDE
$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.
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).

Post by Chris Bonk
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

[jfoug]

Post by magnum
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.

AFAIK, the input string was an ITW format, and thus processed as it is. 
I was provided the input hashes, and wrote the format to use them.  Why
they are the way they are, I can not say for sure.

[Chris Bonk]

Chiming back in.

I solved the issue. I made the mistake of base64 encoding literally the hex
string.

@jfoug is correct.

I needed to modify the derivation and salt to be encoding to base64 from
binary.

I ended up using hashcat, which is currently running.

I hope this helps anyone else if they encounter similar issues.

CB

Post by jfoug

Post by magnum
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.

AFAIK, the input string was an ITW format, and thus processed as it is.
I was provided the input hashes, and wrote the format to use them. Why
they are the way they are, I can not say for sure.

[jfoug]

Post by Chris Bonk
I'm trying to get PBKDF2-HMAC-SHA256 hashes to be loaded. The example hash
below loads just fine.
rounds: 100000
"salt": "e65814e4382759f85550029e723dc7e7",
"5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273"
$pbkdf2-sha256$100000$ZTY1ODE0ZTQzODI3NTlmODU1NTAwMjllNzIzZGM3ZTc=$NWYzN2EzYmQwOGFjMWM3ZDE2MzI5NGEzY2IxOTJlZDE0MDdiNjJiYmM2YTYyNTlmZWU1NWY2ZTUzZjc1NDI3Mw==

PW:  "governor washout beak"

$ ./base64conv.exe -i hex -o mime e65814e4382759f85550029e723dc7e7
e65814e4382759f85550029e723dc7e7  -->  5lgU5DgnWfhVUAKecj3H5w

$ ./base64conv.exe -i hex -o mime
5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273
5f37a3bd08ac1c7d163294a3cb192ed1407b62bbc6a6259fee55f6e53f754273 --> 
XzejvQisHH0WMpSjyxku0UB7YrvGpiWf7lX25T91QnM


Hash:
$pbkdf2-sha256$100000$XzejvQisHH0WMpSjyxku0UB7YrvGpiWf7lX25T91QnM$5lgU5DgnWfhVUAKecj3H5w

$ cat in
$pbkdf2-sha256$100000$5lgU5DgnWfhVUAKecj3H5w$XzejvQisHH0WMpSjyxku0UB7YrvGpiWf7lX25T91QnM

$ echo -n "governor washout beak" | ./john -pipe in
Using default input encoding: UTF-8
Loaded 1 password hash (PBKDF2-HMAC-SHA256 [PBKDF2-SHA256 256/256 AVX2 8x])
Cost 1 (iteration count) is 100000 for all loaded hashes
Press Ctrl-C to abort, or send SIGUSR1 to john process for status
governor washout beak (?)
1g 0:00:00:00  4.219g/s 4.219p/s 4.219c/s 4.219C/s governor washout beak
Use the "--show" option to display all of the cracked passwords reliably
Session completed

@magnum, you can not use base64 on a hex encoded string.  You first have
to 'de' hex it into raw, then base64 that raw data.  That is why I use
the tools available within john.