Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Nov 2016 23:50:54 +0100
From: magnum <>
Subject: Re: John stuck on the same range

On 2016-11-07 20:57, Solar Designer wrote:
> On Mon, Nov 07, 2016 at 10:23:28PM +0300, wrote:
>> After this no more passwords are cracked until john is restarted. Are
>> there any workarounds to this issue?
> (...)
> 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:
> In single.c: single_process_buffer(), change line "if (guessed_keys->count)"
> to "if (0)".

In Jumbo you can actally have this without a hack/recompile. Just 
un-comment the "SingleRetestGuessed = N" in john.conf. You can also tune 
down (or up) the SingleWordsPairMax or skip the login field with 
SingleSkipLogin (if you already did a run with eg. login field only).


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.