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.