[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 09 May 2011 21:18:30 +0200
From: Per Thorsheim <per@...rsheim.net>
To: john-users@...ts.openwall.com
Cc: minga@...ga.com
Subject: Re: Supercharged John the Ripper Techniques by Rick
Redman of KoreLogic
On Mon, 2011-05-09 at 10:09 -0400, Rich Rumble wrote:
> On Thu, May 5, 2011 at 4:07 PM, minga <minga@...ga.com> wrote:
> > Fyi.
> >
> > Rick = Minga = CrackMeIfYouCan = Me.
> >
> > That is my presentation for people "new" to password cracking and not really
> > john experts. I had to remove LOTS of john-specific information from there
> > because I never got in front of an actual group of john-users. i.e. markov,
> > ETC.
> >
> > The URL to that site is private. But sites like that do exist - and are
> > actively being used to compromise stolen passwords. That was the point of that
> > slide. i.e. no one is safe .. blah blah blah.
> >
> > Also - that PDF was made to be geared toward members of OWASP - so there are
> > multiple references to web development/web passwords/etc.
> >
> > -Minga
>
> M$'s password complexity requirements, which I don't think are applied
> by default, and
> only apply to domain accounts (but can be applied to against local
> accounts) have
> the following requirements:
> http://technet.microsoft.com/en-us/library/cc786468%28WS.10%29.aspx
> Passwords must contain characters from three of the following five categories:
> 1 Uppercase characters of European languages (A through Z, with
> diacritic marks, Greek and Cyrillic characters)
> 2 Lowercase characters of European languages (a through z, sharp-s,
> with diacritic marks, Greek and Cyrillic characters)
> 3 Base 10 digits (0 through 9)
> 4 Nonalphanumeric characters: ~!@...^&*_-+=`|\(){}[]:;"'<>,.?/
> 5 Any Unicode character that is categorized as an alphabetic
> character but is not uppercase or lowercase. This includes Unicode
> characters from Asian languages.
>
> These are applied to every AD install I've audited for the past few
> years. I was looking
> through John.conf and noticed the "External:Policy" (as well as a few
> others) mode.
> I see this is a recent addition, and one I plan on testing right now,
> I'd like to make
> changes and additions to cover the various possible combinations, of
> which there are
> many... with 3 of the 5 being the minimum, a password could contain 4
> or all 5 of
> the various requirements.
> The 5th (unicode) doesn't occur much in my experience, so maybe I'll
> focus on the
> other 4 that I do see.
> 8 chars is the minimum I've seen for an AD password in recent years
> this is getting
> longer and longer, and the LM hash is fading from storage as well.
> I'll just poke around
> and mess things up for a bit, then cry for help here later :)
> -rich
Rick: Thx for the additional details on the default password policy of
MS AD. In a corporate world there are several weaknesses of this default
policy, or to be more precise: the standard version of passfilt.dll
built into Windows through the "enforce strong password policy" setting.
Replacing this filter with a customized version of passfilt.dll, which
you can develop easily yourself based on the source code available from
Microsoft, is *highly* recommended (but very few do that..., easily
allowing Password1 as a password).
Another thing to remember is that through the history parameter (number
of passwords to remember in order to prevent password reuse), previous
passwords in their lanman/ntlm form will also be accessible for dumping
through tools like Cain, fgdump, gsecdump etc. I have earlier reported
on several issues with several MS Windows password hash dumpers, so far
without luck or the ability to recreate the problems for the developers.
Cain seems to do it the best way as of today, gladly dumping 24
generations of password hashes per user, into an easily parsed TAB
separated output file. This file has _history_xx applied to every
account name in order to separate each generation of password hashes.
Using this, my friend Jan Fredrik Leversund (twitter: @KluZz)
implemented Levenshtein edit-distance metrics to calculate the edit
distance between each generation of cracked passwords, as well as the
average edit-distance value for every account password history. Nice
stats, easily proving that most of us does the "+1 trick" to their
passwords upon every forced change.
Here's my trick question, not being a programmer nor some kind of genius
like the crop of JtR users seem to be:
Could such statistics based on several generations of passwords from
live corporate environments be used to create hybrid wordlists, where we
take an ordinary wordlist and mangle every word with edit-distance
metrics applied up to a maximum value, in order to "predict your next
password?". Could this be effective? Would it create smaller and/or more
effective hybrid lists (rules)?
--
Best regards,
Per Thorsheim
CISA, CISM, CISSP-ISSAP
securitynirvana.blogspot.com
#passwords11
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
