[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090902155832.GA8033@openwall.com>
Date: Wed, 2 Sep 2009 19:58:32 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: "No password hashes loaded" on Ubuntu 9.04
On Wed, Sep 02, 2009 at 04:48:28AM -0500, Christopher Lemire wrote:
> Has the issue been resolved or close to being resolved?
Not in the proper way yet, and I am likely to work on other things first
(not JtR related even, sorry), but you may try the attached patch, which
I've just put together.
This patch implements generic crypt(3) support. That is, if the
Unix-like system you run JtR on supports your desired crypt(3) hash type
natively, then JtR with this patch applied will also support that hash
type (albeit non-optimally).
Right now, the switch statement in salt() is missing proper checks/code
for the "SHA-crypt" flavors, which means that JtR won't detect matching
salts for this hash type (and won't take advantage of them for faster
processing). (BTW, a related idea is to auto-detect the salt size -
slow but possible.) Yet JtR with this patch applied should be able to
crack weak "SHA-crypt" hashed passwords when running on a proper system.
Please test.
So far, I've only tested this code on an Owl system, with a mix of
traditional DES-based, extended BSDI-style DES-based, MD5-based, and
Blowfish-based ("bcrypt") crypt(3) hashes in the same passwd file - it
worked fine, although indeed slowly (compared to JtR's optimized code
for these hash types).
When there are different hash types in the same passwd file, JtR's speed
(in terms of candidate passwords tried per second) may be mostly limited
by the slowest of the hash types, which may result in JtR effectively
"missing" some weak passwords hashed with the faster hashes (it won't
approach the corresponding candidate passwords soon enough because of
the slow hashes also having been loaded). For this reason, I recommend
that you don't mix different hash types on the same JtR instance, even
though this code supports that.
> I plan to
> write a guide on my blog (see signature), and setup john the ripper
> clusters. It won the poll on my site for next topic, and I haven't
> been able to supply what's in high demand right now. Things involving
> security seem to be the highest in demand.
I recommend that you primarily use better-supported hash types for
demoing this. You don't have to run JtR against hashes from your
specific Ubuntu system, although now you should be able to. It is a
little bit weird to run, say, a cluster of 4 machines (or CPU cores or
whatever) when the same performance could be achieved with 1 machine
once proper code is written for JtR.
> http://linuxinnovations.blogspot.com/
(Offtopic: your blog feels overloaded with slow JavaScript and images.)
You write:
"The problem is that since the md5 hash exploit code has been released.
Most or all of Linux quit using md5 hashes to store their passwords.
They now use SHA256."
This is largely misinformation (I counted four factual errors), based on
rumors that are only partially based on fact. I suggest that you learn
the subject matter before you write about it. If you don't know and
don't have time to figure something out for real, you could want to word
your comments accordingly. For example:
"The problem is that JtR does not yet support the newer hash type being
used by my Ubuntu 9.04 system. You can read more about the problem here."
(with the same hyperlink that you currently have). Yes, this is less
info, but at least it's correct. If you really wanted to write what you
did, then you could use words such as "apparently" or "I've heard that".
Please treat this as constructive criticism.
Thanks,
Alexander
View attachment "john-1.7.3.1-generic-crypt-1.diff" of type "text/plain" (5751 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.
