0

I am attempting to encrypt some passwords by hand to use in a project with JtR. Unfortunately, the program is having difficulty recognizing the hash types of the passwords after hashing them.

Currently, based on the information found here: John the ripper does not crack password my process is to encrypt a password via openssl using AES-256, then piping the result into sha256sum on the command line

echo -n "password" | openssl enc -aes-256-cbc -a | sha256sum | cut -f 1 -d " " > hash.txt

The result for this being

enter image description here

I have also attempted piping the encrypted password directly into openssl's passwd function, although this has been less successful than the previous command

echo -n "password" | openssl enc -aes-256-cbc -a | openssl passwd -1 -salt xx > hash.txt

In any case, john does not seem to be able to recognize the hash format.

enter image description here

What exactly is happening here? It should be simple enough for JtR to recognize the encrypted hash, but obviously something is being mangled in the process. Is there an additional newline or other improper character being piped in along with the encrypted password? If someone could enlighten me it would be greatly appreciated.

Kaiser2500
  • 11
  • 2

1 Answers1

0

You're telling John to decrypt a raw SHA256 hash, but you're creating hashes of an AES-256 encrypted string, not of the password itself. Because the AES-256 encrypted string is effectively a very random blob, John is unlikely to ever guess it.

Try, instead, simply hashing the password and then running John against it:

root@kali:~# echo -n password | sha256sum | awk '{print $1}' > hashes.txt
root@kali:~# john --format=raw-SHA256 hashes.txt
Using default input encoding: UTF-8
Loaded 1 password hash (Raw-SHA256 [SHA256 256/256 AVX2 8x])
Warning: poor OpenMP scalability for this hash type, consider --fork=4
Will run 4 OpenMP threads
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:/usr/share/john/password.lst, rules:Wordlist
password         (?)
1g 0:00:00:00 DONE 2/3 (2020-04-19 14:17) 10.00g/s 655360p/s 655360c/s 655360C/s 123456..gbby
Use the "--show --format=Raw-SHA256" options to display all of the cracked passwords reliably
Session completed
root@kali:~# john --show --format=raw-SHA256 hashes.txt
?:password

1 password hash cracked, 0 left
root@kali:~#
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • "You're telling John to decrypt a raw SHA256 hash, but you're creating hashes of an AES-256 encrypted string, not of the password itself." It seems I misunderstood what JtR does in the first place, or even how passwords are stored in /etc/shadow! In fact, upon further research it seems JtR was only meant to break hashes rather than direct encryption - which makes sense given how each is generated and how one would check that(correct me if I am mistaken). In any case, your proposed solution works great, thanks so much for your help! – Kaiser2500 Apr 19 '20 at 18:53