[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jan 2010 23:39:52 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: getting started, unix_crypt hashes
On Wed, Jan 13, 2010 at 06:49:23PM +0000, Paul Needham wrote:
> Considering this was the first time I had ran JtR, I was concerned when JtR seemed to just pause/freeze after importing the hashes, almost as if it was expecting an additional command. So I was unsure if the process was working.
I am considering introducing a "novice" mode, to be enabled by default,
where JtR would print verbose messages/hints - e.g., a line that would
say "Running. Press "any" key for status, Ctrl-C to abort." An "expert"
user will be able to disable these annoying messages in the config file.
> However, I noticed if I press the "-" key on my keyboard it gives me some feedback on what JtR is doing, as shown below:
JtR will print a status line like this on almost any keypress. I usually
press the spacebar.
> guesses: 0 - ?
The number of successfully cracked password hashes (out of those
initially loaded for cracking).
> time: 0:00:00:09 - I expect this is how long the attempted crack has been running for?
Correct.
> (3) - ?
This is the current cracking mode. When you don't force the use of a
specific cracking mode, JtR starts with "single crack" mode (1), then
goes into wordlist mode with word mangling rules (2), and finally
proceeds with "incremental" mode (3). Because you had so few hashes to
crack and because you did not provide a large wordlist, JtR got to
"incremental" mode within seconds.
> c/s: 489829 - ?
This is the average effective cracking speed measured in combinations
(of {target hash, candidate password}) per second. You will likely get
a higher number here if you let the session run for longer (because
there's more overhead during the first few seconds).
> trying: doneh - dorny - I expect this is the current attempted cracks John is trying against the hash?
Yes, that's the "range" of candidate passwords being tested at the
moment of your keypress. JtR is often testing many candidate passwords
at once (this is specific to some low-level algorithms that it uses), in
which case it will be displaying the first and the last candidate
password that it happens to have buffered at the moment.
You may be able to obtain more information in the log file, which is
called john.log by default.
> For anyone who has successfully cracked a password using the tool, when JtR cracks 1 of the password hashes, does it inform the end-user? Or do we need to periodically enter a command to see what has been cracked, and what the tool is still working on.
JtR will print the cracked password and the corresponding username right
away, but in general this information is not guaranteed to be complete
(although in a simple case like yours it should in fact be complete).
In order to be sure to receive complete information regarding passwords
cracked so far, you need to use the "john --show passwd" command after
JtR terminates (or is interrupted). You may also use "john --show"
(from another terminal) while JtR is running, but it may be missing the
last few minutes of results. On a Unix system, you may send the SIGHUP
signal to the running "john" process in order to have it update the
files and have "john --show" provide the most up-to-date results (I am
not sure about Windows). There are several reasons for a possible
discrepancy between JtR's output while cracking and "john --show". One
of the reasons is that JtR might avoid loading duplicate hashes for
cracking, whereas "john --show" will show matches against all passwd
file lines.
> The other thing I wondered, is has JTR been developed so that if it detects the hashes are the traditional unix_crypt, will it keep the crack combinations <=8 characters long,
Yes, it is aware of the target hash type's limitations like this.
> as to my knowledge such passwords cant exceed 8 characters, therefore attempting a 10 character string would be a pointless exercise?
Not exactly. A user may well be typing a 10 character string for their
password, and the system truncates such passwords to 8 characters. So
it makes sense for JtR to do the same. However, it is pointless to test
multiple candidate passwords that differ only in characters beyond the 8th.
JtR attempts to avoid such effectively-duplicate candidate passwords
(trying only one of them), but to a limited extent because detecting
all duplicates in all cases would be too costly. For example, if you
have your wordlist sorted alphabetically and you have the word
"abbreviate" immediately followed by "abbreviation", then only one of
them will be tried as a candidate password (properly truncated) against
a traditional crypt(3) hash. However, if the wordlist is not sorted
alphabetically, then both may be tried (wasting some CPU time).
JtR's "incremental" mode, where JtR generates candidate passwords fully
on its own, will indeed not go beyond the target hash type's maximum
supported password length.
> Or do I need to tailor the settings to suit possibilities of unix_crypt passwords?
No, the default settings work well for all supported hash types.
> I guess the obvious one would be formulating a word list only consisting of words or phrases of <=8 characters long.
No. You would actually miss some weak passwords if you remove longer
words/phrases from your wordlist. This is because users are generally
unaware of the length limitation and the system truncates longer inputs.
I hope this helps.
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.
