[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP943058A283B058393F86A3FD070@phx.gbl>
Date: Mon, 28 May 2012 00:15:42 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: UI for MJohn
On 05/27/2012 02:16 PM, Aleksey Cherepanov wrote:
> Say we track attack's ratio of cracked password to
> candidates count (are there better properties for success? it could be
> tricky to go this way with incremental mode) so to estimate attack's
> success we compare this ratio with some value we consider successful
> (for instance if every 1000 candidates gives 1 password then attack is
> successful).
An attacks success can only be measured in relation to other attacks.
The "expected" success (number of cracked passwords per tried number of
candidate passwords) will also vary over time.
At the beginning of a cracking session, it is easier to crack some
hashes. The more hashes have been cracked, the harder it usually becomes
cracking more hashes.
> But how to estimate coverage? For that user should take
> one attack and then look over all related attacks. It does not seem
> right for me.
I don't understand what you mean with coverage.
Do you mean how much of the total key space has been covered by the
various attacks that have been tried?
> I think it could be solved storing separately meta-attacks that lack
> some certain information and contain more general properties. For
> instance pattern could be applied to different hash types thus giving
> us one attack per hash type. That attacks differs only by hash type.
> So if we look onto all attacks and pick only those with different hash
> types then we could generalize them into such meta-attack.
But due to the different properties of these hash types, many attacks
can only be tries against fast hashes, because they would take too much
time against slow salted hashes.
> But as of
> meta-attack is not connected with john's cmd-line directly we could
> populate properties like 'applied to hash type X = yes/no' so it will
> be easy to search on them. To apply such meta-attack to new hash type
> we need just to alter one regular attack that consists in that
> meta-attack.
Yes, I think this is useful. Try attacks on the fastest hash types (or
those saltless hash formats with the highest number of hashes) first.
See which attacks work best, and apply those to other formats, starting
with the next fastest hash format...
(For slower hash types, don't try the complete attack, but try to find a
smaller subset which could be tried...)
> (I think user should see not only name of attack in web
> ui but start of cmd-line to modify it.) Meta-attack is not something
> magical, it is just a way to group similar attacks together to have
> easy access to advanced statistics (that involves more than one real
> attack), but thinking about them like about attacks gives ability
> search them like regular attack.
>
> I'd say that we could only meta-attacks generalizing real attacks on
> the fly but we could group attacks in different directions. As you
> said we could alter hash type but also we could alter something other.
Yes, another example could be:
The old attack used several rules, and a word list file.
The modifies attack uses the same set of rules, but another, larger word
list.
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.
