[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150504162706.GA27728@openwall.com>
Date: Mon, 4 May 2015 19:27:06 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [Johnny] Task 1.5.1 Manual plaintext guessing
On Mon, May 04, 2015 at 03:51:25PM +0300, Shinnok wrote:
> > On May 4, 2015, at 3:47 AM, Mathieu Laprise <mathlaprise@...il.com> wrote:
> >
> > Also, regarding this feature "Manual plain-text guessing for individual ciphers (directly in the table view)", can you please describe a use case. I'm not sure to understand the concept of "ciphers". Is the use case : "the user try to guess the password for a user in the table view and we verify if he's right or not " ?
>
> Task is [1.5.1] Manual plain-text guessing for individual ciphers (directly in the table view).
>
> What I long thought would be a nice feature is having the ability to manually test guesses for a single(and maybe multiple?) set of hashes already loaded in Johnny. Most likely by using a separate column in the main table view of loaded hashes.
>
> I know that this can simply be achieved by simple using or editing a dictionary in the wordlist mode as far as JtR is concerned.
>
> Let's drive the discussion:
> 1. Would this be useful for anyone else besides me? My reasons include:
> a) quickly verify a known ciphertext - plaintext combo;
For non-salted or for fast salted hashes, it is better to check
plaintext against all hashes.
BTW would user like to apply rules onto the input?
> b) "I'm feeling lucky" guesses;
It may lead user to inefficient behaviour. On the other hand, it may
be an interesting interface to run wordlist attacks not managing
explicit files.
> 2. Can we easily implement this with JtR(is the dictionary approach the only one)?
Dictionary approach is not the only: --stdin (or --pipe) may be used.
It may be interesting because this way you can feed 1 john with words
not starting it again and again. Though --fork is not applicable then.
--stdin is supported by core and jumbo now. --pipe is supported only
by jumbo, it allows application of rules then.
--skip-self-tests may be used to skip self tests, they may be the
biggest part of start up time. Though it has drawbacks: sanity of john
should be checked at least once (for each format in use).
I propose to not care about the speed now. It would be a premature
optimization.
Dictionary attack means that johnny creates a file. A user may be not
happy that his words were written to disk.
On the other hand a user may be happy to track words used and reuse
them later.
> 3. Should it be a transparent step/action that runs as a one shot task and results in an answer on the spot? (i.e. we don't have to start an actual cracking session)
It depends on the number of words to guess, number of hashes to try
against and their complexity. Also if you apply rules then the task
may be very long. If the cracking is really quick then it may be good
to not draw it as a session.
> 4. Will this collide with an existing session for the current john.pot?
.rec file will be created, if default file is locked then john would
not be started.
All guessed passwords from all johns are written to one john.pot
(unless you specify other .pot file with --pot=).
I see that as an input field below the table to input words. It may be
multiline and allow copy-pasting (to paste from browser). Extending
this view: word splitter may be applied to split the text by white
spaces and/or punctuation. Also the checkbox and combobox for rules may
be there. The input may be queued instead of immediate start and end.
To extend word splitting: it may be useful to allow to paste URLs
instead of text, then the text is downloaded and stored as files with
the URL in metainformation. It may (or may not) be a nice interface
for wordlist attacks not limited to manual guesses.
Thanks!
--
Regards,
Aleksey Cherepanov
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.
