|
Message-ID: <20050514231911.GA28280@openwall.com> Date: Sun, 15 May 2005 03:19:11 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Comparing John session files and more Michael, On Fri, May 13, 2005 at 10:39:57AM +0200, Michael Behrisch wrote: > While testing a passwd (of say 1000 users) the users keep on > changing passwords, thus one could try to check the new > passwords whenever they reached a certain limit (say 100). > In order not to loose the progress on the remaining 900 > passwords I would like to stop the first process, start another > john just checking the 100 new ones and joining the two > when the second reached the state of the first. That's fine, but there's the complication you mention below. > The following questions occur: > Is it save to restore a session with a different passwd than > it was interrupted with? Usually, yes. But this means editing the recovery file, which is an undocumented territory and subject to change without notice. You need to realize that in "single crack" mode the candidate passwords John will try depend on the password files' content. But "single crack" is quick, so you probably were not going to do this trick to it. Other issues may arise with changed or multiple hash types in your password files. > How do I know whether the second process did catch up? > (At the moment I do compare the rule number in wordlist mode > and the entry number in incremental mode which are both recorded > in the .rec file. Is that the right thing to do?) Yes, -- if this is sufficient precision for you. In "incremental" mode, you need to realize that you have to wait for the entry number to become greater than it is in your original run on the full file. It is insufficient to wait for the numbers to become equal since there may be a large number of candidate passwords to try for each entry and your original John run might be already past a significant fraction of those. > Attached You will find my bash-script which runs as a daily cron job. > Maybe it's helpful. Thank you for sharing this with the list, -- other John users might find this useful. > DIFF="diff --old-line-format='' --unchanged-line-format=''" FWIW, a more traditional approach (and one which does not rely upon GNU extensions) is to use "sort" and "comm" for this. -- Alexander Peslyak <solar at openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments
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.