[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101122232025.GA21154@openwall.com>
Date: Tue, 23 Nov 2010 02:20:25 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: pwgen
Albert, Minga, all -
I just gave my proposed approach a try, and I got some curious results
(see below the quoted text):
On Wed, Nov 17, 2010 at 09:51:01PM +0300, Solar Designer wrote:
> $ ./pwgen -1cn 8 1000000 | sed 's/^/:/' > john.pot
> $ wc -l john.pot
> 1000000 john.pot
> $ sort -u john.pot | wc -l
> 997936
> $ ./john -make=pwgen.chr
[...]
> Successfully written charset file: pwgen.chr (62 characters)
[...]
> I experimented with the above a year ago. I only had one specific
> password hash to attack (a client's lost password), so I did not proceed
> to figure out the actual percentages, etc. for incremental mode runs on
> multiple hashes of pwgen'ed passwords. I also did not use pwgen.chr
> during the KoreLogic contest; maybe it would have helped a little bit
> since according to info KoreLogic released after the contest 1000 of
> the passwords were actually pwgen'ed (random-1000-from-pwgen.txt).
I used the pwgen.chr file generated above to attack three sample
password hash files. They were generated with:
$ ./pwgen -1cn 8 1000 > test1k-1
$ for n in `seq 000 999`; do ./pwgen -nc; done > test1k-2
$ ./gennthash.pl < test1k-1 > pw-nt-test1k-1
$ ./gennthash.pl < test1k-2 > pw-nt-test1k-2
$ ./gennthash.pl < random-1000-from-pwgen.txt > pw-nt-test1k-kore
where ./pwgen is my local build of pwgen 2.06, ./gennthash.pl is the
second script from this posting:
http://www.openwall.com/lists/john-users/2008/06/18/3
and random-1000-from-pwgen.txt is KoreLogic's file released after their
contest:
http://contest.korelogic.com/plaintexts/random-1000-from-pwgen.txt
I defined my incremental mode as follows:
[Incremental:pwgen]
File = $JOHN/pwgen.chr
MinLen = 8
MaxLen = 8
CharCount = 62
Running it against pw-nt-test1k-1 and pw-nt-test1k-2 with "--format=nt"
(that is, attacking the not-so-weak NTLM hashes, not the weaker LM ones)
cracks many passwords almost instantly, and there's almost no difference
between these two in this respect (even though the passwords themselves
are different). Specifically, 60 passwords from each file (120 total)
get cracked in under 2 minutes by two simultaneous processes running on
a Core i7 920 2.67 GHz (without parallelization - that is, each process
using at most one CPU core at a time). 105 from each file are cracked
by 8 minutes 30 seconds (just an arbitrary moment when I pressed a key
in both terminals). 156 from each file are cracked by 24 minutes,
170 are cracked by 32 minutes (the moment I am writing this). That's
6% cracked in 2 minutes, or 17% cracked in half an hour.
Of course, the times to crack would be much bigger for better hash
types, but the percentages of "quickly"-crackable passwords would be
similar - for a totally different definition of "quickly". For example,
2 minutes at NTLM could translate(*) to 2 days at a single FreeBSD-style
MD5-based crypt(3) hash, giving a 6% chance of it getting cracked in the
2 days or a 17% chance in 32 days. This is non-negligible risk.
Consider, for example, that hashes of this type are currently in use by
RIPE and are publicly available from their whois servers.
(*) This is not just an arbitrary guess. NTLM is a single invocation of
MD4 (plus some overhead). FreeBSD-style MD5-based crypt(3) is 1000
iterations of MD5 (plus different overhead). MD5 is slightly slower
than MD4. There are 1440 minutes in a day. So a 1-minute attack
against NTLM is similar to a 1-day attack against FreeBSD-style
MD5-based crypt(3). This theory matches JtR's speeds at these two hash
types pretty well.
Now, when I try the same pwgen.chr attack on Kore's passwords, I get no
luck. Nothing gets cracked in 2 minutes. When I ran the attack against
their original NTLM hashes list (from the contest), not limited to
random-1000-from-pwgen.txt, only one password got cracked in 40 minutes,
and this one did not come from random-1000-from-pwgen.txt. What does
this mean? Was random-1000-from-pwgen.txt generated in a different
manner? Or does pwgen's behavior differ between machines/systems it is
being run on? (Assuming that its randomness source is good, I would not
expect any differences like this.)
Minga - please "document" how random-1000-from-pwgen.txt was generated.
Meanwhile, my John runs are up to 195 (out of 1000) passwords in 1 hour.
Thanks,
Alexander
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.
