[john-users] Reading salt that contain semicolum

[Jeroen]

Hi,

Some hashing algorithms use salts that might - and do in some cases -
contain semicolums. John seems to do some magic, effectively skipping
the hash.

***@dev:~$ echo
'0123456789abcdef0123456789abcdef$123456789012345678901234567890' >
/tmp/hash
***@dev:~$ /opt/JohnTheRipper/run/john --format=dynamic_2006 /tmp/hash
Using default input encoding: UTF-8
Loaded 1 password hash (dynamic_2006 [md5(md5($p).$s) (PW > 55 bytes)
256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=8
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:03 3/3 0g/s 383538p/s 383538c/s 383538C/s bilbark..107969
Session aborted
***@dev:~$ echo
'0123456789abcdef0123456789abcdef$1234567890:2345678901234567890' >
/tmp/hash
***@dev:~$ /opt/JohnTheRipper/run/john --format=dynamic_2006 /tmp/hash
Using default input encoding: UTF-8
No password hashes loaded (see FAQ)
***@dev:~$

Is there a workaround? HEX$ encoding the salt doesn't seem to be
successful.

Thanks,

Jeroen

[Jeroen]

Hi,
Some hashing algorithms use salts that might - and do in some cases - contain
semicolums. John seems to do some magic, effectively skipping the hash.
'0123456789abcdef0123456789abcdef$123456789012345678901234567890' > /tmp/hash
default input encoding: UTF-8 Loaded 1 password hash (dynamic_2006
[md5(md5($p).$s) (PW > 55 bytes)
256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=8 Press 'q' or
Ctrl-C to abort, almost any other key for status 0g 0:00:00:03 3/3 0g/s
'0123456789abcdef0123456789abcdef$1234567890:2345678901234567890' > /tmp/hash
Is there a workaround? HEX$ encoding the salt doesn't seem to be successful.
Thanks,
Jeroen

To prevent misunderstandings: the salt can contain any ASCII 7-bit character. In large sets all ASCII printable characters are present. So --field-separator-char doesn't work without introducing issues with for salts. Using a field separator of an 8 bit value that is not used in the salts, e.g. 0x80, results in a 'trying to use an invalid field separator char: € (must be single byte character)'.

Thanks,

Jeroen

[Matt Weir]

Hi Jeroen,
This is a pretty common problem, and unfortunately until you run
across it it's hard to find the solution, so I'm glad you asked :) The
solution is in the John the Ripper documents in the DYNAMIC file. I'm
going to quote the relevant part:

--------------------------------------------------------------------------------------------------------------------------------------
Salts can contain some problematic characters. Some of these would be
characters such as: : \r \n \ NULL, etc. The : (colon) char is used
by JtR as a field separator. If it exists in the salt, it will split
the salt into multiple fields (i.e. wrong). A carriage return or line
feed, will cause the line to split, and JtR to not read it right.
NULL bytes are a problem in any C file, using normal 'string' functions.
The \ char, is used as a quoting char within dynamic, and can cause issues.
One other recently found issue, is if the salt ends in ' ' or '\t' (space
or tab), then if the dyna hash is placed on a line by itself (i.e. without
a user: prepended), then jtr will trim the whitespace off. This is a known
issue, and this is just a bad side effect of a known wanted behavior where
the raw hash files are cleaned up during processing.
DUE to all of these problems, dynamic has been expanded to take this as
the salt: $dyanamic_#$base_16_hash$HEX$hex_bytes_of_salt. In this
format, if the salt was 1234, then $HEX$31323334 would be the equivalent
value. This allows salts such as $\x0:\r\nBadSalt to actually be encoded.
This salt CAN be used, if you use the representation:
$HEX$003a0a0d42616453616c74.
There is an application in ./run which can 'help' This is ./run/raw2dyna
This process will convert files in the format of hashCsalt (c can be any char),
into the proper $dynamic_#$hash$salt It can also handle saltChash (if
salt is a fixed size). It also properly handle the problematic characters,
and uses the $HEX$hex_salt method, if there are bad characters in the salt.
------------------------------------------------------------------------------------------------------------------------------------

Good luck, and I hope this helps!

Matt

Post by Jeroen

Hi,
Some hashing algorithms use salts that might - and do in some cases - contain
semicolums. John seems to do some magic, effectively skipping the hash.
'0123456789abcdef0123456789abcdef$123456789012345678901234567890' > /tmp/hash
default input encoding: UTF-8 Loaded 1 password hash (dynamic_2006
[md5(md5($p).$s) (PW > 55 bytes)
256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=8 Press 'q' or
Ctrl-C to abort, almost any other key for status 0g 0:00:00:03 3/3 0g/s
'0123456789abcdef0123456789abcdef$1234567890:2345678901234567890' > /tmp/hash
Is there a workaround? HEX$ encoding the salt doesn't seem to be successful.
Thanks,
Jeroen

To prevent misunderstandings: the salt can contain any ASCII 7-bit character. In large sets all ASCII printable characters are present. So --field-separator-char doesn't work without introducing issues with for salts. Using a field separator of an 8 bit value that is not used in the salts, e.g. 0x80, results in a 'trying to use an invalid field separator char: € (must be single byte character)'.
Thanks,
Jeroen