[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP32348FD6C91D389C1FD9144FD030@phx.gbl>
Date: Wed, 23 May 2012 03:46:59 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: UI for MJohn
On 05/17/2012 09:10 PM, Aleksey Cherepanov wrote:
> During the contest we used mailing list and irc channel for
> everything: to talk about attacks, to track attacks in run, to
> coordinate.
IMO, one problem was that team members didn't participate as much (or as
effective) in the communication as would have been desired.
Some users (me included) didn't use the IRC channel, some didn't even
use the mailing list.
This is what made coordinating and avoiding duplicate effort somewhat
difficult.
I don't want to blame those users. Probably they had good reasons.
May be the existing communication channels were not considered to be
that useful by all team members.
May be it was just more fun trying out own ideas instead of coordinating
with others.
So, if we want better / more effective communication / coordination, we
have to make it easy for the users.
Either by increasing the perceived value of communication, or by
reducing the effort required to communicate.
If users get an easy to use tool to suggest possible attacks, to review
attacks suggested by others, see the results of those attacks, and so
on, this might help the motivation to communicate and coordinate.
It might also help motivation if a user who is running out of ideas what
to try next can use his own hardware to process attacks suggested by others.
Or if a user who has lots o good ideas what attacks to try, but limited
hardware resources, he might be motivated to communicate his ideas if he
sees his suggested attacks being run on other users' hardware.
> Also there were some team members that was able to talk directly being
> at defcon. They did meetings and talks out of the list and channel. I
> think that does not need any special user interface: like with mailing
> list and private talks one should write down conclusions with reasons
> possibly and make them public (available to other members).
I agree.
> It seems that there are two kinds of talks: general coordination and
> talks related to certain attack.
What is "general coordination"?
Coordinating who is making use of which available hardware?
Discussing what ad-hoc scripts might be necessary (verifying john.pot
lines submitted by team members, detecting patterns, generating
candidate passwords for newly detecteed patterns)?
> The latter could be grouped to or
> even fill attack's description. I think there should be a separate
> place for each attack and related talks.
While it is interesting to be able to connect planned/running/finished
attacks with attack descriptions and discussions related to an attack, I
think more important is to think about how should an attack be specified.
Usually you have:
-file with password hashes (or some subset)
-hash format (may be we decide to make sure each file just contains
hashes of one format, but in a contest scenario there might be ambiguous
hash formats and you don't know which hash belongs to which format)
-general attack type:
--single
--wordlist
--incremental
--external
--markov
Depending on the general attack type, you have additional parameters:
-word list file
-rule[s] (or a List.Rules subsection (of an existing config file) with a
list of rules
...
So may be when specifying the attack, the user has to pick the general
attack type using a drop-down list (or may be, the list of general
attack types is presented as a list of radio buttons instead), then,
depending on the attack type, the user has to specify other parameters:
-word list file name, to be selected from a list of existing file names
(we might need to provide a way to add new wordlist files)
-list of rules. e.g.:
l
cQ
$[120-9]
Alternatively, we could require that the user uploads a particular
config file (or just copies the config file contents from the clipboard)
and specifies command line options.
The server could provide some templates for minimal config files
depending on the attack type, e.g., a config file for --wordlist=
doesn't need any Incremental sections.
May be we need to verify the attack description is syntactically correct
before we allow a client to fetch the description.
This can be done on the server, adding --max-run-time=1 and
--pot=dummy.pot to the command line and replacing the password hash file
with a sample file containing just one hash, to avoid a huge run time
and memory consumption for loading large hash files...
It should also be easy to create new attacks by adjusting a copy of an
old attack.
E.g., when a particular attack was successful, a user might want to try
the same attack on a different set of hashes, or the same set of rules
with a different (larger) word list, and so on.
> Also attack status should be
> shown there. In case of rare status changes they could be posted as
> messages but when they are frequent it would be more appropriate to
> show only last status, only current state without history.
>
> So my view of this is to have web based ui similar to weblog or forum
> with updates in head: separate page for each attack with head message
> for updates and with comments for discussion. Also there could be a
> global chat for general talks.
There should also be some way to compare, sort, filter attacks according
to various attributes, to detect which attacks were more successful than
others...
> While web uis are common and there is an ability to take premade
> solution for this there are also drawbacks.
>
> First problem with that solution is that not all deployment
> environments will be satisfied with only chat and forum (even
> threaded, like modern blogs have) for talks, they could prefer
> video/audio conferencing. All users could not be satisfied and it
> could be better to think how to make it easy to integrate things with
> system and not how to pull them inside.
>
> At this time I think that built-in chat is not needed. External
> program without any integration could be suitable because chatting is
> not persistent.
Yes.
> The same applies to video/audio conferencing and to
> direct conversations (that would be hard to integrate with any
> software).
I am happy that you don't suggest integrating a speech recognition
software into the scope of this GSoC project ;)
> Other problem is that web uis are not perfect in general. For instance
> some (at least me) members of john-users team could prefer mailing
> list over forum and irc over web-based chat. So it could be useful to
> think about ability to have different full front ends. I think it is
> possible to do but I doubt it would be enough easy for that summer.
> But we could start with ui specific for john-users and then add other
> uis (after summer). Is it needed? Would not it be too selfish for
> gsoc?
I think it is important to have a consistent way to present the known
attacks, so that users can easily see what has been tried, what has been
suggested, but not yet tried, ...
If you want to provide different ways to add attack descriptions (web
based + mail interface or whatever, that is probably OK, as long as all
those attack descriptions end up in the same repository.
I think it is important to first get one mechanism of entering attack
descriptions working without problems.
(This should be a mechanism which is easy to use for the majority of
users, which probably means: web based. But I am open for alternative
suggestions.)
> Or even there could be ui that uses only emails: user sends mails with
> commands or with text to server, depending on commands or their lack
> these messages are public (just messages, attack descriptions) or
> private (attack progress requests). Other option is to have separate
> address for personal commands and for public commands or to have an
> interface like ezmlm have for archive requests.
>
> Further more user could have a local mail-server that talks with
> master server though other protocol.
I don't think this is a good suggestion, because most team members will
have difficulties setting up a mail server.
We need to keep in mind that the solution should be easy to use for team
members.
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.
