headers
Luke O'Connor | 7 Dec 2009 01:08
Picon

password ranking

Hello everyone,

I used to be involved in cryptographic research, and still retain a strong
interest in password,
in particular around the analysis of password guessing, the size of password
spaces defined
by policies and so on.

What I was wondering was whether there is a document which describes the
search strategy
that is followed by JtR. I see from the documentation pages that many search
options can be
configured but I was hoping someone could give me a simple answer based on
standard settings
(if they exist).

Imagine that I start JtR to search for a password like 8h2wt6ghw - expressed
as windows hash
for example - how many guesses will JtR make before the password will be
found? Let's for the
moment assume that JtR runs indefinitely.

I think an interesting measure of password complexity would be some function
JtR(Password)
which returns the position of Password in the list of candidate passwords
generated by JtR
according to its search strategy.

Is there any analysis along these lines, a document which describes how a
given search strategy
(Continue reading)

Permalink | Reply | 7 comments |
headers
Solar Designer | 7 Dec 2009 03:24
Favicon

Re: password ranking

On Mon, Dec 07, 2009 at 01:08:40AM +0100, Luke O'Connor wrote:
> What I was wondering was whether there is a document which describes the
> search strategy that is followed by JtR. I see from the documentation
> pages that many search options can be configured but I was hoping someone
> could give me a simple answer based on standard settings (if they exist).

Default settings and default data files do exist, but there can be no
answer that would be simple, correct, and complete at the same time.

> Imagine that I start JtR to search for a password like 8h2wt6ghw - expressed
> as windows hash for example - how many guesses will JtR make before the
> password will be found? Let's for the moment assume that JtR runs
> indefinitely.

This is either tricky or time-consuming to compute.  You could in fact
write a program that would compute this reasonably quickly for the
"incremental" mode (with given settings and .chr file), but such a
program does not readily exist (as far as I'm aware) and it is not a
trivial one to write.

> I think an interesting measure of password complexity would be some function
> JtR(Password) which returns the position of Password in the list of
> candidate passwords generated by JtR according to its search strategy.

JtR's "incremental" mode tries candidate passwords roughly in order of
decreasing estimated probability of each being "the" password.  (With
multiple hashes loaded for cracking this would have to be worded a bit
differently, but the main idea holds.)  The probability estimate is
roughly the product of conditional probabilities of the characters in
each character position in the candidate password.  The conditional
(Continue reading)

Permalink | Reply | 6 comments |
headers
Solar Designer | 7 Dec 2009 04:06
Favicon

Re: -nodupes option of JimF patch broken (not works at all)

On Sat, Nov 21, 2009 at 03:09:36PM +0100, Ze0n Kat wrote:
> After compile john the ripper in windows under cygwin, and apply jumbo and
> then JimF patch... tested and works good, but the option of JimF patch
> -nodupes is broken and not works at all.
> 
> If someone can fix it.

I was hoping that someone else (perhaps Jim) would reply, but it seems
that I have to.  "Doesn't work" is generally not a sufficiently
informative problem report.  For a useful bug report, you need to
include:

1. Information on the software involved (including the compiler and OS)
and its versions.  OK, you've almost provided this above. :-)

2. Your exact test case.  This would be the command you run and its
input files (reduced to the required minimum to reproduce the problem -
perhaps just a few lines).  Of course, it may also be a good idea to
avoid including hashes of actual passwords (replace them and state so
explicitly, yet make sure the problem can still be reproduced).

3. Expected behavior (e.g., this-many hashes loaded).

4. Actual behavior (the output from JtR actually received).

At the very least, you needed to mention what you thought the
"non-working" option was supposed to achieve (but did not).

It is quite possible that this will result in someone identifying and
explaining what you might have understood incorrectly (wrong
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Marechal | 7 Dec 2009 07:50

Re: password ranking

Solar Designer a écrit :
> However, there is a wiki page on the Markov mode, which is an unofficial
> addition to JtR (found in the jumbo patch):
> 
> http://openwall.info/wiki/john/markov

It includes a tool that computes the complexity of any password based on 
this search mode, and let you deduce the maximum number of passwords 
that have to be computed before it successfully matches. IMO this 
strength estimation is not so bad, and it leads to nice charts.
Permalink | Reply | 1 comment |
headers
Jim | 7 Dec 2009 22:05
Picon

RE: -nodupes option of JimF patch broken (not works at all)

I think this may be the problem.  There are a couple of places where there
were !db->options->nodupes was being checked, but in the 'wordlist' mode
(default now if the wordlist is smaller in size), this code was not 
present.  Thus in wordlist mode, the -nodupes switch was not being honored.
I think this (hope at least) that this is the bug listed.  Also the nodupes
option variable was not being set (but a flag was).  That flag was not
accessable
at certain points at runtime, so I simply changed options.c to set the older

variable in the loader section of the options structure.

diff -urpN john-1.7.3.4-jimf-after-jumbo-2/src/options.c
john-1.7.3.4/src/options.c
--- john-1.7.3.4-jimf-after-jumbo-2/src/options.c	Thu Oct 29 03:53:56
2009
+++ john-1.7.3.4/src/options.c	Mon Dec  7 20:55:58 2009
 <at>  <at>  -244,4 +244,7  <at>  <at>  void opt_init(char *name, int argc, char
 	}
+
+	if (options.flags & FLG_NODUPES)
+		options.loader.nodupes = 1;

 	if ( (options.flags & FLG_SHOW_SET) && options.showuncracked_str) {
 		if (!strcasecmp( options.showuncracked_str, "left"))  {
diff -urpN john-1.7.3.4-jimf-after-jumbo-2/src/wordlist.c
john-1.7.3.4/src/wordlist.c
--- john-1.7.3.4-jimf-after-jumbo-2/src/wordlist.c	Wed Oct 28 19:46:48
2009
+++ john-1.7.3.4/src/wordlist.c	Mon Dec  7 20:57:33 2009
 <at>  <at>  -317,7 +317,7  <at>  <at>  void do_wordlist_crack(struct db_main *d
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke O'Connor | 7 Dec 2009 22:46
Picon

Re: password ranking

Alexander,

great reply, let me take some time to digest this before I reply any
further

rgs Luke

On Mon, Dec 7, 2009 at 3:24 AM, Solar Designer <solar@...> wrote:

> Default settings and default data files do exist, but there can be no
> answer that would be simple, correct, and complete at the same time.

[... many paragraphs skipped ...]

> I hope this helps.
>
> Alexander
Permalink | Reply | 2 comments |
headers
Matt Weir | 8 Dec 2009 03:46
Picon
Favicon

RE: password ranking

Hey Luke,
  First, I read your blog http://lukenotricks.blogspot.com/ and I really
enjoy it. I'm actually writing my dissertation on password cracking and I've
spent a lot of time struggling with the very same problem you posted. Fist,
as Simon said, his Markov model includes a really nice option to estimate
the strength of a password against Markov based bruteforceing. 

  Second, the guys at electricalalchemy.net did a great write-up on their
experiences using Amazon's EC2 service to do cloud password cracking. They
were only doing pure-brute force, (not even letter frequency analysis
enhanced), so their overall estimates aren't very accurate, (JtR's
Incremental and Markov modes blow that out of the water), but still it can
give you a nice estimate on how much it would cost to make a certain number
of guesses.  The three posts on that are:

http://news.electricalchemy.net/2009/10/cracking-passwords-in-cloud.html
http://news.electricalchemy.net/2009/10/password-cracking-in-cloud-part-5.ht
ml
http://news.electricalchemy.net/2009/11/cracking-passwords-in-cloud-q.html

I've been writing a couple of blog entries on how the 10k hotmail password
set faired against the different brute force methods supported by John the
Ripper, (aka pure-bruteforce, letter frequency analysis, incremental, and
Markov). I'm currently finishing one up on dictionary based attacks and
hopefully will have it up by the end of the week. The six current posts are:

http://reusablesec.blogspot.com/2009/10/10k-hotmail-passwords.html
http://reusablesec.blogspot.com/2009/10/analysis-of-hotmail-passwords-by-oth
er.html
http://reusablesec.blogspot.com/2009/10/analysis-of-10k-hotmail-passwords-pa
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matt Weir | 8 Dec 2009 04:03
Picon
Favicon

JtR 1.7.3.4 64bit build for MacOSX Snow Leopard

All,
   I've had a lot of people request this, so I uploaded a copy of a
pre-build executable, (+source), for a fully patched, (with JimF's patches),
version of JtR 1.7.3.4 with the 64 bit build for MacOSX Snow Leopard. Feel
free to redistribute this, and let me know if there are any problems, or
additional builds you would like me to make.

Here it is:

http://sites.google.com/site/reusablesec/Home/john-the-ripper-files/pre-buil
t-john-the-ripper-builds?pli=1

Thanks,
Matt Weir
Permalink | Reply | 1 comment |
headers
websiteaccess | 8 Dec 2009 15:03
Picon

Re: JtR 1.7.3.4 64bit build for MacOSX Snow Leopard

On Mon, 7 Dec 2009 22:03:02 -0500, Matt Weir wrote:
> All,
>    I've had a lot of people request this, so I uploaded a copy of a
> pre-build executable, (+source), for a fully patched, (with JimF's patches),
> version of JtR 1.7.3.4 with the 64 bit build for MacOSX Snow Leopard. Feel
> free to redistribute this, and let me know if there are any problems, or
> additional builds you would like me to make.
> 
> Here it is:
> 
> http://sites.google.com/site/reusablesec/Home/john-the-ripper-files/pre-buil
> t-john-the-ripper-builds?pli=1
> 
> Thanks,
> Matt Weir
> 
> 
> 
Thanks Matt

 I have posted a benchmark John 1.7.3.4 SSE2 Vs John 1.7.3.4 64 bits 
(SSE2 was compiled by me, 64 version by Matt).
 Benchmark done on my Imac Quadcore I7

 You can download the results at 

http://rapidshare.com/files/318007943/comparatif_john_SSE2_64_bits_1_feuille_Mise_en_page_1.pdf.zip.html

 Enjoy.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke O'Connor | 8 Dec 2009 16:21
Picon

Re: password ranking

Great Simon, I have printed out the orginal paper and will follow-up

rgs Luke

On Mon, Dec 7, 2009 at 7:50 AM, Simon Marechal <simon@...> wrote:

> Solar Designer a écrit :
>
>  However, there is a wiki page on the Markov mode, which is an unofficial
>> addition to JtR (found in the jumbo patch):
>>
>> http://openwall.info/wiki/john/markov
>>
>
> It includes a tool that computes the complexity of any password based on
> this search mode, and let you deduce the maximum number of passwords that
> have to be computed before it successfully matches. IMO this strength
> estimation is not so bad, and it leads to nice charts.
>
>
>
>
Permalink | Reply | 0 comments |

Gmane