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.