Date: Mon, 6 Aug 2012 20:10:22 +0200 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-dev@...ts.openwall.com Subject: Re: johnny: how to handle sessions? On 08/06/2012 06:16 PM, Aleksey Cherepanov wrote: > I tried to understand how I see work with sessions in Johnny. And I > see problems. > > For new attacks I think to use just names. These names would refer to > sessions in some dir in home. I guess this dir is ~/.john . ~/.john doesn't need to exist, especially, if john has not been built system-wide. Another alternative would be, to store the rec files under ~/.config/Openwall/Johnny, if we keep the config file under ~/.config/Openwall. I am not yet sure what is the best option. But switching the directory if we decide to change the location shouldn't be such a complicated change. (But if we have to assume a significant user base, we should maintain compatibility with code that has been released earlier. IMO, currently no such user base exists.) A separate directory for rec files created by johnny would also prevent problems with incompatible rec files from command line invocations. On a command line, a user can specify multiple password files. Currently, johnny is limited to one file (which is OK, don't try to change this now). > To restore user opens .rec file in johnny. Johnny reads it and opens > respective passwd file. (Also johnny could set settings like they were > before session creation so user see what the session is.) But it needs > to read and parse session file that is considered bad. I think getting a single file name from a .rec file (and showing an error message when a .rec file contains multiple file names for hashes) is OK, at least for now. (A jumbo version can still get an extended --list= interface for such tasks.) > I could imaging other approaches that connect file with its sessions > (by sha1 I guess). But using them Johnny would not support sessions > created from command line. May be this is a good thing, at least for the version we create during GSoC. > Will we document session file format? Unlike MJohn that creates its > own sessions always Johnny would support seamless migration between > gui and cli. I guess it is a good feature. OTOH johnny could be viewed > as a viewer for progress that is able to start john but do not connect > this starts with files viewed. > > How do you see sessions in johnny? If we limit johnny to support sessions created from within johnny, you could even store the relevant information that connects file name(s), options, and so on to sessions in the config file. [Session.first-run] password_file [Session.wl-rockyou] password_file --wordlist=/path/rockyou.txt Upon start, you can parse which Sessions exist in the config, remove sessions from the config if the .rec file disappeared (assume the session finished), and so on. Limit the characters that can be used for session names, and don't distinguish upper and lower case. (Because FAT wouldn't allow Test and test at the same time.) > What should I do before summer end? What will we do later? I'd say, support just a single session (not necessarily names john, may be make it --session=[some-path/]johnny) before the first release of a tarball and Debian / rpm package. If johnny.rec exists, and the user wants to run a new attack, warn that the old session file will be overwritten. Extending the scope to support multiple sessions should only be considered if we are sure we don't run into problems with the other mandatory tasks. Before we have a tarball and rpm and debian package ready, we don't know how long that will take. Once you managed to produce all these, you'll know how long it would take to repeat all this in another iteration, after adding the next set of features (like multiple session names). Frank
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.