John the Ripper password cracker users

Aleksey Cherepanov | 4 Jul 2012 17:26

Aleksey's status report #11

I missed my status report yesterday. Sorry!

My previous status report is on john-dev.

During this week I finished skeleton of client side. So now I am about
to make a skeleton of server side. I already tested request tracker's
speed and tried redmine but did not tried to fill them with reasonable
amount of tickets yet because I already got problems with about empty
database.

On my Debian box redmine works well out of the box but request tracker
is too slow. It takes 5 seconds to create ticket using cli and 1
second to update it (when there are changes, setting the same values
is much faster). Web ui is not better. It is abnormal. There should be
some misconfiguration.

Nevertheless I plan to use request tracker as is for skeleton to try
the whole process in action. Speed does not matter now. Though I do
not want to spend much time on this. Request tracker's cli seems to be
easy to use so I hope to make rough integration of client side with rt
right today.

I did not yet fixed everything that Frank pointed me out after
previous status report.

Done

> - Draft implementation of client side

It seems to be done.

(Continue reading)

headers

Frank Dittrich | 4 Jul 2012 22:10

Re: Aleksey's status report #11

On 07/04/2012 05:26 PM, Aleksey Cherepanov wrote:
> I did not yet fixed everything that Frank pointed me out after
> previous status report.

It is not necessary to "fix" everything.
Just keep in mind what might have to be dealt with at some point, and
when/how you want to deal with it (a workaround with limited
functionality might be OK as a first step), or point out where you
disagree with me (and possibly, why you disagree).

> That is my primary priority. Though it will be a bare bone thing.
> 
> - Try to fix request tracker to get reasonable speed
> 
>> - Look into other possible collaboration server side tool
>> - Compare them by speed
> 
> - Apply Frank's suggestions from status report #10
> 
>> - Fix markup on the wiki page
> 
>> - Research possible statistics and their importance

Can you elaborate a little more what statistics you have in mind?
(If it had already been discussed, just a pointer to a previous thread
would be nice.)

Frank

(Continue reading)

headers

Aleksey Cherepanov | 10 Jul 2012 09:30

Re: Aleksey's status report #11

On Wed, Jul 04, 2012 at 10:10:30PM +0200, Frank Dittrich wrote:
> On 07/04/2012 05:26 PM, Aleksey Cherepanov wrote:
> > That is my primary priority. Though it will be a bare bone thing.
> > 
> > - Try to fix request tracker to get reasonable speed
> > 
> >> - Look into other possible collaboration server side tool
> >> - Compare them by speed
> > 
> > - Apply Frank's suggestions from status report #10
> > 
> >> - Fix markup on the wiki page
> > 
> >> - Research possible statistics and their importance
> 
> Can you elaborate a little more what statistics you have in mind?
> (If it had already been discussed, just a pointer to a previous thread
> would be nice.)

One thing is efficiency: ratio of cracked passwords to count of
candidates. This could be real: by fact .pot length divided to john
--stdout ... | wc -l (currently I use new pot for each attack and
(plan to) filter cracked hashes out from file to crack). But this has
problems: if attacks overlap efficiency is low while attack could be
good in general, it could affect our decisions to proceed attack or
not badly.

On the other hand we could calculate absolute efficiency: like there
were not other attacks, i.e. ratio of totally cracked passwords found
among candidates to candidates count. This does not take overlaps into

(Continue reading)

headers

Aleksey Cherepanov | 10 Jul 2012 23:30

Re: Aleksey's status report #11

On Tue, Jul 10, 2012 at 11:30:25AM +0400, Aleksey Cherepanov wrote:
> On Wed, Jul 04, 2012 at 10:10:30PM +0200, Frank Dittrich wrote:
> > On 07/04/2012 05:26 PM, Aleksey Cherepanov wrote:
> > > That is my primary priority. Though it will be a bare bone thing.
> > > 
> > > - Try to fix request tracker to get reasonable speed
> > > 
> > >> - Look into other possible collaboration server side tool
> > >> - Compare them by speed
> > > 
> > > - Apply Frank's suggestions from status report #10
> > > 
> > >> - Fix markup on the wiki page
> > > 
> > >> - Research possible statistics and their importance
> > 
> > Can you elaborate a little more what statistics you have in mind?
> > (If it had already been discussed, just a pointer to a previous thread
> > would be nice.)
> 
> One thing is efficiency: ratio of cracked passwords to count of
> candidates. This could be real: by fact .pot length divided to john
> --stdout ... | wc -l (currently I use new pot for each attack and
> (plan to) filter cracked hashes out from file to crack). But this has
> problems: if attacks overlap efficiency is low while attack could be
> good in general, it could affect our decisions to proceed attack or
> not badly.

Hmm, we already talked about efficiency. The link
http://openwall.com/lists/john-users/2012/05/27/2

(Continue reading)