Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Aug 2005 10:27:04 -0600
From: Stephen Cartwright <>
Subject: Re: trivial parallel processing (4 CPUs)

Breaking the password file apart randomly causes duplicate salts to be used 
across the password files, but what if you broke the password file apart 
based upon salt?

Then for every salt, there would only be 1 set of passwords still. right?

Another thing I am wondering about is how does John crack partial passwords? 
Many passwords have just two or three characters cracked. However I thought 
that with a hash, the output varies widely depending on the input. This 
should means that you can not just try words and see if some of the 
characters match up. Since this is obviously not the case (unless I am 
missing something), how is it possible to find these partial passwords?



On 8/26/05, Solar Designer <> wrote:
> On Fri, Aug 26, 2005 at 10:46:33AM -0600, Stephen Cartwright wrote:
> > What I ended up doing is I got a huge dictionary (found every wordlist
> > I could and then stripped out all non-printible characters, converted
> > all uppercase to lowercase, sorted and uniqed to give about a 50 mb
> > wordlist)
> It is not clear to me why you had to do that on your own. You could
> have simply downloaded this:
> or you could have purchased it and more on CD:
> > then I broke up the passwd file into four sections
> That way you've likely made the hashes per salt ratio worse for all 4
> instances, thereby decreasing the effective c/s rate.
> How many password hashes did you have in your full password file (the
> halves, the way John reports them on load)? If it's under 1000, then
> the hit of using this approach is not that bad. However, if you had,
> say, 10,000+ of them, then there may be no gain from running this on 4
> CPUs like that (as opposed to using just one CPU) - and you need to use
> a better approach (see below).
> Basically, you need to add up the numbers of different salts as reported
> by your four instances of John and compare that against the number of
> different salts that one instance of John would report when run on the
> original password file. If these numbers are close, you're fine. If
> there's a substantial difference, that is how much processing power
> you're wasting by using this approach.
> > and just
> > ran 4 seperate instances of John (in four different directories) --
> You did not need to use different directories. They can share the same
> john.pot just fine - this is a feature. You merely needed to supply
> different session names.
> > one on each section. I am using the default settings except for the
> > new wordlist.
> Do you mean, you've changed the "Wordlist = ..." in john.conf, then ran
> the 4 instances with no options (for batch mode)? OK, that would
> explain why you needed different directories.
> > Does this sound like optimal usage for my 4-cpu machine?
> No - see above about the hashes per salt ratio.
> > Any reccomendations?
> 1. You need to run "single crack" on all of your accounts at once. John
> might crack more passwords this way.
> ./john -single passwd
> 2. It is unimportant whether or not you distribute wordlist-based
> cracking over all of your CPUs. However, if you do, you may want to
> split the wordlist into 4 parts and not split the password file. Rather
> than use 4 separate directories, you'd run:
> ./john -se=w1 -w=words1.lst -rules passwd
> ./john -se=w2 -w=words2.lst -rules passwd
> ./john -se=w3 -w=words3.lst -rules passwd
> ./john -se=w4 -w=words4.lst -rules passwd
> (on four different terminals - or simply background the commands and
> logout).
> 3. Once you're done with the wordlists, proceed with "incremental" mode
> as I had suggested in my previous response (have different instances try
> different password lengths).
> Of course, you can script these three steps.
> 4. Set "Idle = Y" in john.conf.
> 5. Oh, and you should be using John 1.6.38 (development) - or whatever
> version is current - for best performance.
> > One more thing... I have been getting some false posititves. Some
> > passwords have worked fine, but others that JTR found did not work.
> > Any idea why?
> It is unrealistic that John would crack a password "wrongly". More
> likely, the system has other measures preventing access to those
> accounts, like account or password expiration. It is also possible that
> another password database is being consulted at login time, not the
> password file which you've grabbed.
> --
> Alexander Peslyak <solar at <>>
> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
> - bringing security into open computing 
> environments
> Was I helpful? Please give your feedback here: 

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.