[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110316224541.GA9444@openwall.com>
Date: Thu, 17 Mar 2011 01:45:41 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Password file hash type analysis in JtR
Robert,
I probably misunderstood your original request on this. I had two
related and relevant enhancements planned:
1. Continue to detect other hash types when loading password hash files
for cracking (even after successful initial autodetection of a certain
"sticky" hash type). That way, the user won't inadvertently miss hashes
of those other types.
2. "--show" output enhancements, including output in formats other than
same-as-input (/etc/passwd or pwdump-like). This could include CSV.
So far, I implemented #1 (will be in 1.7.7), but not #2. I didn't feel
that #2 had much to do with "hash type analysis", hence it did not occur
to me that this was what you might have been referring to. I am still
planning to implement #2 (in a post-1.7.7 version).
On Sun, Feb 27, 2011 at 10:51:32PM -0500, Robert Harris wrote:
> Why not output in more than two columns? I don't see the need to combine
> different information in one column.
Actually, "john --show" already uses many columns - usually as many
colon-delimited columns as the input file has. However, it only
replaces the contents of one of the columns (hashes to cracked
passwords). Yes, it could make sense to use different output formats,
including more than one John-generated column.
> Something like this is a good start?
>
> Username Password Hashtype
Right now, "john --show" is not always aware of the hash type. It will
report literal matches (between the password hash files and john.pot)
even when the hash type is not detected (maybe not supported) by the
copy of JtR that you use for reporting. Yes, it could output the hash
type when known... although there are also cases when the hash type is
not known reliably (the string in john.pot would be valid for more than
one hash type). Perhaps such ambiguities should be reduced by
consistently marking detected hashes in split() with hash type tags
going forward, like we've been doing in many cases already. The hashes
in john.pot would always be non-ambiguous then.
> Since we're on the subject of formatting the output, I'd like to purpose a
> potential new variable and output format to be used with the "--show".
> Please discuss here and consider implementing.
>
> But first some background.
>
> When I do a password audit, I'm usually doing it for many servers. I
> usually name the password file the same name of the server. If it is a unix
> server I combine the <server-name>.shadow and <server-name>.password file
> with unshadow, then the resulting file is called <server-name>. I usually
> run john with the * to do all this files in the directory, but this gets
> tricky when it is time for the results. I have to run john --show with
> each file name. I do this with a perl script. Since I frequently find a
> good amount of passwords, this perl script also outputs the show rules in
> comma delimited format. I also make sure I include the file name (which
> happens to be the server name), in the comma delimited output (which is to
> one file). That way, I can easily sort my results any way I like, in a
> spreadsheet program.
>
>
> So, I would love to see John be able to natively output in comma delimited
> format (like with --show-comma-delimited).
I think it will be "--show=csv".
> Also it would be nice for it to
> accept a user variable that it would tack on the end of comma delimited
> line. (This user variable could be used as the name of the server.) Or
> maybe it could automatically tack on the name of the file to the end of the
> line.
I'd prefer it to use the filename.
> So, it could look something like this:
>
> John --show-comma-delim Server-A --uservariable=Server-A
>
> "UserId","Name on Account","Password","Hashtype","Uservariable"
> "rharris","Robert B. Harris","changeme1","sha-1","Server-A"
>
>
> So, having this output would drastically reduce the need for us to have a
> script to support getting the output into a sortable format.
Understood and agreed.
> We would still need to have a script to go through each file's results with
> show, unless that changes too. Perhaps it should!? Since starting the
> audit can take a wildcard input to start the audit on all files in the
> directory (like john *), why can the show output do the same.
"john --show" is already usable on multiple files at once; it's just
that without a filename field in its output you get a mix of results for
your different files.
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.
