Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
use_john_the_ripper_to_crack_password_hashes [31.01.2021 01:52] – created Pascal Suter | use_john_the_ripper_to_crack_password_hashes [02.02.2021 09:50] (current) – [Use John The Ripper to crack password hashes] Pascal Suter | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Use John The Ripper to crack password hashes ====== | ====== Use John The Ripper to crack password hashes ====== | ||
+ | I often hear rumors about how fast a password hash (such as a linux passwd/ | ||
+ | I am not a security expert and by no means a Hacker, but i've wanted to try the script-kiddie approach myself hands on for a long time already. I was recently tasked with stress-testing some systems in our lab with significant compute power. One of them was a 128 core AMD ROME based server, the other one one was a GPU server with 8x NVIDIA RTX 2080Ti in it. So finally i took this opportunity to verify or bust the myth, that a teenager with a gamer notebook can crack your password hash in a few hours. | ||
+ | Well Spoiler alert: the myth is absolutely busted, IF your password is a safe password, meaning, it is not on a password list and of significant length. Once the wordlist based approach fails, the only option left to track is to brute-force the password, which means, to try all possible combinations of all possible characters of a password. Now if we know a password policy, that actually might help to narrow down the possible passwords and accelerate the brute force attack slightly by being able to remove un-allowed passwords (like for example all passwords that don't contain at least one upper and lowercase letter and digit, if our policy demands all three are present in a password). So ironically, the more restricting your policy, the less permutations are possible and the easier it is to crack your password.. so be careful what you wish for by publishing password policies ;) | ||
+ | |||
+ | So again, once we are past the wordlist approach and we need to start brute-forcing, | ||
+ | So at the end of the day, if you just want to hack somebody' | ||
+ | |||
+ | In any case, Ideally, you should start by first hacking into some large GPU based clusters in order to get massive calculating power for free, this will help with the profitability of such an attack :) | ||
+ | |||
+ | so can a kid with a gamer notebook crack your safe password within hours? most probably not! | ||
+ | |||
+ | Things look quite different, if your password is on one of those lists.. with 1.5 million passwords per second, those lists are processed quite fast ;) so you better choose a safe password for your critical applications. The longer the better of course. Even better than that: don't allow password logins in the first place.. especially not for users with fixed names such as '' | ||
+ | |||
+ | In any case, here is the full description how i set up the various systems and what performance i got out of them using John the ripper, one of the most popular password hash cracking utilities. | ||
[[https:// | [[https:// | ||
Line 9: | Line 23: | ||
../ | ../ | ||
===== use john with openMP on multiple cores ===== | ===== use john with openMP on multiple cores ===== | ||
+ | export OMP_NUM_THREADS=8 | ||
+ | john ~/ | ||
+ | |||
+ | ===== use john with multiple cores by forking the process ===== | ||
john --fork=8 ~/ | john --fork=8 ~/ | ||
Line 15: | Line 33: | ||
===== compile john with MPI support to run on clusters ===== | ===== compile john with MPI support to run on clusters ===== | ||
+ | ubuntu dependencies | ||
sudo apt install libopenmpi-dev openmpi-bin | sudo apt install libopenmpi-dev openmpi-bin | ||
+ | centos dependencies / preparation: | ||
+ | yum install openmpi-devel openmpi openssl-devel | ||
+ | module load mpi/ | ||
+ | |||
+ | get source and compile: | ||
wget https:// | wget https:// | ||
tar xvf 1.9.0-Jumbo-1.tar.gz | tar xvf 1.9.0-Jumbo-1.tar.gz | ||
Line 26: | Line 49: | ||
to check the progress run | to check the progress run | ||
kill -USR1 $(pidof mpirun) | kill -USR1 $(pidof mpirun) | ||
+ | | ||
+ | ===== compile with OpenCL support to run on NVIDIA (and other) GPU's (tested on CentOS) ===== | ||
+ | download and install cuda if you haven' | ||
+ | wget https:// | ||
+ | sudo sh cuda_11.2.0_460.27.04_linux.run | ||
+ | wget https:// | ||
+ | tar xvf 1.9.0-Jumbo-1.tar.gz | ||
+ | cd john-1.9.0-Jumbo-1/ | ||
+ | ./configure LDFLAGS=-L/ | ||
+ | the summary should show that OpenCL support is now enabled (yes) | ||
+ | make -s clean && make -sj4 | ||
+ | now let's run it :) here is an example where I ran john the ripper on a server with 8x NVIDIA GeForce RTX 2080 Ti: | ||
+ | run/john --format=sha512crypt-opencl -dev=gpu -fork=8 | ||
+ | the '' | ||
+ | run/john --list=formats --format=opencl | ||
+ | to get a list of all crypts that support opencl. if you are lucky, the one you are looking for is in there as well :) | ||
+ | |||
+ | the '' | ||
+ | |||
+ | ===== continue an interrupted session ===== | ||
+ | John saves its status as it's working, so in case it crashes or you have to abort it because you need to work with your pc and don't want the cpu load on it for example, you can always resume the session and continue where John has left off. | ||
+ | |||
+ | BUT.. it is **important** that you specify the '' | ||
+ | |||
+ | so you would start john like this: | ||
+ | john --session: | ||
+ | and then resume the session like so: | ||
+ | john --restore: | ||
+ | also the other commands like for example '' | ||
+ | john --status: | ||
+ | |||
+ | |||
+ | ===== Performance examples ===== | ||
+ | if you press any key during the run, you will get a status showing you c/s (crypts per second). here are a few numbers from the systems i had access to at the moment of writing this article: | ||
+ | ^ CPU / GPU ^ c/s rate ^ method used ^ | ||
+ | | 8-core i7-8809G CPU| 7'500 | OpenMP | | ||
+ | | 128-core (2 socket) AMD ROME 7742| 150' | ||
+ | | 8 x GeForce RTX 2080 Ti | 8x190' | ||
+ | |||
+ | |||
+ |