Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 27 Feb 2011 22:51:32 -0500
From: "Robert Harris" <rs904c@...scape.net>
To: <john-users@...ts.openwall.com>
Subject: RE: Password file hash type analysis in JtR

Alex and John-Users,

Why not output in more than two columns?   I don't see the need to combine
different information in one column.

Something like this is a good start?

Username       Password     Hashtype


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).  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.

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. 

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.


I hope I explained this well.

What do you think?

-Robert B. Harris from VA

-----Original Message-----
From: Solar Designer [mailto:solar@...nwall.com] 
Sent: Saturday, February 26, 2011 6:45 AM
To: john-users@...ts.openwall.com
Subject: Re: [john-users] Password file hash type analysis in JtR

On Mon, Jan 24, 2011 at 08:01:45PM -0500, Robert Harris wrote:
> Potential new output:
> 
> The following password hash format(s) was/were discovered in the input
file
> <file>:
> 
> <format1>
> 
> <format2>
> 
> ...
> 
> <formatx>

This has been on my to-do for ages, and I've just implemented it for the
upcoming 1.7.7.  The current output is:

$ ./john pw-fake-unix
Warning: only loading hashes of type "des", but also saw type "bsdi"
Warning: only loading hashes of type "des", but also saw type "md5"
Warning: only loading hashes of type "des", but also saw type "bf"
Loaded 3269 password hashes with 2243 different salts (Traditional DES
[64/64 BS MMX])
Remaining 3026 password hashes with 2073 different salts
pianoman         (u2508-des)
kirk             (u1154-des)
[...]
swordfis         (u2757-bigcrypt:1)
[...]
chiara           (u1852-des)
christop         (u1861-des)
guesses: 127  time: 0:00:00:00 0% (1)  c/s: 120242  trying: pianoman -
people
Passwords printed while cracking might be partial
Use the "--show" option to display all of the cracked passwords reliably
Session aborted

As you can see, it became a lot more verbose - maybe too verbose even?
Comments are welcome.

The detection/reporting of other hash types is currently only
implemented when the "--format" option is not specified.  It is assumed
that the person using "--format" is already aware of what hash types
they have.  This provides a way to avoid the performance overhead of
detection of other hash types.

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.