|
Message-ID: <003801cbd6fa$c9adf4e0$5d09dea0$@net> 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.