Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 19 Jun 2008 00:12:50 +0400
From: Solar Designer <>
Subject: Re: interpretation of results

On Wed, Jun 18, 2008 at 09:00:01AM +1200, Russell Fulton wrote:
> I have been running a bunch of UNIX DES hashes and have one cracked:
> [ .jtr]$ john --show unix.pass
> root::14007::56::::

OK.  BTW, this is not relevant to your question, but you should run JtR
against combined passwd and shadow files (use the included "unshadow"
program/symlink), not just against the shadow file.  This makes a
difference for the "single crack" mode.  I understand that you might
have run it against the shadow file above in order to not reveal
irrelevant info in your posting. ;-)

> I don't think the password is null (there is a hash for it) or is  
> there a distinction between no password and a null one (which makes  
> sense)?

The issue is that some systems, in some cases, will in fact generate
hashes of empty strings instead of leaving the passwd or shadow file
field empty.  This does not make much sense as intended behavior, but it
sort of makes sense as a somewhat common peculiarity.  The systems might
or might not treat such cases equally when authenticating users (e.g.,
as it relates to possible "permit empty passwords" settings).

> It was cracked at the start of the incremental run so it is clearly  
> something short ?

That's right.  The "Incremental:All" mode will in fact try zero-length
(empty) candidate passwords:

# Incremental modes
File = $JOHN/all.chr
MinLen = 0
MaxLen = 8
CharCount = 95


To unsubscribe, e-mail and reply
to the automated confirmation request that will be sent to you.

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.