+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: Cracking SHA1(linkedin) (/thread-9449.html)
Pages:
1
2
RE: Cracking SHA1(linkedin) - mailmuncher2000 - 02-14-2021
Yes the odds of that happening are 1 in (2^(160-20 bits)) = 1/2^140 ~ 1 in 1.39e42
Yet it seems someone may have discovered such a collision:
source: https://www.win.tue.nl/~aeb/linux/john/john.html
"LinkedIn hashes:
After the release of 6.5 million LinkedIn hashes, a patch JtR-Jumbo-5-LinkedIn-SHA1.diff for john was published that handles the raw-sha1_li format of SHA1 with the first twenty bits zeroed. Be careful:
% echo -n sunshine09 | shasum
3b1787e7bd710592ee36264a72d6aa35c2d165f9 -
% grep `echo -n sunshine09 | shasum | cut -c6-40` combo_not.txt
a96807e7bd710592ee36264a72d6aa35c2d165f9
000007e7bd710592ee36264a72d6aa35c2d165f9
Here ‘sunshine09’ is a password that fits the second, but not the first hash. (If the first hash is an actual password hash, this is a very remarkable coincidence: a 140-bit SHA1 near-collision.) By mistake the formats raw-sha1 and raw-sha1_li are both labeled dynamic_26."
RE: Cracking SHA1(linkedin) - mailmuncher2000 - 02-14-2021
Actually the situation is a bit worse. hashcat only checks the last 16 bytes of the sha1 hash
$ echo -n 'testing123' | sha1sum
4c0d2b951ffabd6f9a10489dc40fc356ec1d26d5 *-
$ hashcat -m 100 -a3 --outfile-autohex-disable --potfile-disable 000000001ffabd6f9a10489dc40fc356ec1d26d5 testing123
000000001ffabd6f9a10489dc40fc356ec1d26d5:testing123