|
Message-ID: <20120420120117.GA29663@debian> Date: Fri, 20 Apr 2012 16:01:17 +0400 From: Aleksey Cherepanov <aleksey.4erepanov@...il.com> To: john-users@...ts.openwall.com Subject: Re: identifying patterns to successfully crack more passwords On Thu, Apr 19, 2012 at 07:22:15PM +0400, Aleksey Cherepanov wrote: > On Thu, Apr 19, 2012 at 01:46:11AM +0400, Aleksey Cherepanov wrote: > > On Sun, Apr 15, 2012 at 10:32:59PM +0200, Frank Dittrich wrote: > > > > During contest search of patterns was very valuable. > > > > > > Yes. Did you think about ways to make that easier, e.g., detect patterns > > > automatically, and decide in which sequence to try those patterns > > > on the remaining password hashes? > > > > > > What if you detect patterns in cracked passwords submitted by other > > > users, and after trying to find more passwords with the same patterns > > > you realize there are no more such passwords because the user already > > > tried all password candidates for these patterns? > > > You'll have wasted time due to duplicated effort. > > > Can you think of ways how to prevent this (more or less automatically > > > instead of manually)? > > > > My general idea is to not allow users to crack passwords on their own: instead > > they should upload attack description (suitable for dispatching), and then the > > system will dispatch attack and mark it as finished. So we would not waste > > time on reverse engineering of work some user already did. > > Other approach is to have patched or wrapped john that reports its invocation > information and progress so user uses it like regular john and all users see > how it is invoked, what attacks are in run, finished, and even overlap of > attacks. Such approach separates distribution from collaboration. Though it is > more low level so if someone uses script that calls john several times there > will be several attacks while logically there is one attack described by the > user's scripts. Also this approach does not deprecate use of Johnny the GUI to control john. I think it is very promising approach because it could be made modular so different parts does not need the whole infrastructure to do their job. Regards, Aleksey Cherepanov
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.