[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
