[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240124155516.GA16585@openwall.com>
Date: Wed, 24 Jan 2024 16:55:16 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: DES passwords not cracked within hours
On Wed, Jan 24, 2024 at 02:14:16PM +0100, Matthias Apitz wrote:
> Now I have another use case and using the same installation 'john' is
> unwilling to crack a single line password file in hours:
This happens. Not every password is easily crackable.
> What I do wrong?
Not exactly wrong, but there are a few things you can do to improve your
chances and speed this up:
Easy:
Upgrade to latest JtR off our GitHub. We've made relevant improvements
since the 1.9.0-jumbo-1 release. Those include better default
password.lst and rules, and faster comparison of computed vs. loaded
descrypt hashes on CPU.
Use "--fork=4" to run processes instead of threads. Unfortunately, our
current code has a performance bottleneck when running against few or no
different salts (in your case, there's only one hash, and so only one
salt), which is avoided by usage of separate child processes. This
should roughly double the cumulative speed on your system.
Harder, but more effective:
Focus the attack if you know anything about the password. You can limit
lengths, use mask mode. However, if you don't know anything specific
about the password, then running latest JtR with the defaults is good.
Use faster hardware - GPUs ("--format=descrypt-opencl"), FPGAs
("./configure --enable-ztex" if you have the hardware), or larger CPUs
(more cores, AVX-512). On GPUs or FPGAs, you'll need to use mask mode
(maybe along with another mode, see doc/MASK).
On fast enough hardware, you can reduce the worst-case time for a
printable ASCII password from years to weeks.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
