[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Nov 2016 20:57:52 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: John stuck on the same range
On Mon, Nov 07, 2016 at 10:23:28PM +0300, e.yarmash@...il.com wrote:
> I'm using john (1.8.0-jumbo-1-5389-gdcefafb+ OMP) to crack some (simple)
> bcrypt hashes (~1M). I run `john --session=mysession hashes.txt`.
> However, after some time john stucks on the same range and the status
> starts to look like this:
>
> 32g 0:00:58:11 1/3 0.009166g/s 193.3p/s 463.6c/s 463.6C/s mgnb13..f9141480
> 32g 0:00:58:12 1/3 0.009163g/s 193.2p/s 463.6c/s 463.6C/s mgnb13..f9141480
> 32g 0:00:58:13 1/3 0.009161g/s 193.2p/s 463.6c/s 463.6C/s mgnb13..f9141480
> 32g 0:00:58:47 1/3 0.009072g/s 191.3p/s 463.6c/s 463.6C/s mgnb13..f9141480
> 32g 0:00:58:48 1/3 0.009070g/s 191.3p/s 463.6c/s 463.6C/s mgnb13..f9141480
> 32g 0:00:58:54 1/3 0.009054g/s 190.9p/s 463.6c/s 463.6C/s mgnb13..f9141480
> 32g 0:00:58:55 1/3 0.009052g/s 190.9p/s 463.6c/s 463.6C/s mgnb13..f9141480
> 32g 0:00:59:16 1/3 0.008998g/s 189.8p/s 463.6c/s 463.6C/s mgnb13..f9141480
>
> After this no more passwords are cracked until john is restarted. Are
> there any workarounds to this issue?
You're running JtR without specifying a cracking mode. This means it
tries "single crack" mode first, and would then proceed to other modes.
"Single crack" mode targets individual hashes (or rather salts, but in
your case it's probably 1 hash per salt anyway) with information
specific to those users (their usernames, etc.) Whenever this leads to
a successful guess, that guessed password is then queued to also be
tested against all other hashes (other salts).
bcrypt is slow, but it's nevertheless reasonably quick to test e.g. a
username (treating it as candidate password) against its corresponding
hash, and for weak passwords quite often there will be a match. This is
why you see those 32 guesses here. Now, once you've had some successful
guesses, they need to be tested against all other hashes, which are
unrelated to where the information came from (not same username and hash
anymore). The likelihood of getting a match here is way lower. With
faster hashes or/and fewer hashes (or rather with fewer different salts)
loaded for cracking total, this is still fast enough, which is why it's
implemented. However, for a million of bcrypt hashes this can be taking
painfully long. It may still pay off in the long run, but when you'd
like to maximize the number of guesses early on, you don't want this
extra check to be performed yet. Here's how to hack JtR to remove it:
http://www.openwall.com/lists/john-users/2015/08/21/1
In single.c: single_process_buffer(), change line "if (guessed_keys->count)"
to "if (0)".
Also note that you won't run into this issue with modes other than
"single crack", but with those you also won't get the weakest
username-based passwords cracked as quickly. So you actually do want
"single crack" here, just without this extra check initially.
Once you're ready to perform an equivalent of this extra check, you may
use the "--loopback" mode to do it, or better yet you'd process your
cracked passwords through "unique" and use that as a wordlist.
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.
