[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 May 2015 17:54:55 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: [Johnny] Task 1.5.1 Manual plaintext guessing
> On May 4, 2015, at 7:27 PM, Aleksey Cherepanov <lyosha@...nwall.com> wrote:
>
>> 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.
>
>
I'd like to take the simplest approach as possible for this small feature:
1. Separate johnHandler; Thus no session. Single question that stands is different john session name vs. don't allow running this feature if there's a current cracking session active?
2. Use --stdin method;
3. Passphrase will be tested agains all hashes since there's no simple way of doing otherwise ;
4. Isn't --skip-self-tests jumbo only? We don't need to think about it if so;
5. Single pashphrase at a time. Anything different than that falls into the wordlist attack category.
6. Input at the bottom of the table view is fine. It could also be a button in the actions toolbar with a popup message box.
Shinnok
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.
