[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060201152911.GB8668@openwall.com>
Date: Wed, 1 Feb 2006 18:29:11 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: roadmap
On Mon, Jan 30, 2006 at 05:25:55PM +0000, Phantom wrote:
> Solar Designer <solar@...> writes:
>
> >Just set "Idle = Y" in john.conf (or john.ini) - the current versions of
> >John support that already, and it works on both Unix and Windows. Maybe
> >"Idle = Y" should be made the default, but I'm afraid that John would be
> >getting unfair benchmarks against its "competition".
>
> Ok, but then a setting for each CPU would be nice.
> So one could have Idle0=N and Idle1=Y :)
This may feel "nice", but it's not needed in practice. Your opinion
could differ. :-) But let's not discuss this detail of a possible SMP
implementation any further - it's just a waste of everyone's time.
On renaming the "single crack" mode:
> Hmmm, not only about usernames? But the usernames ARE the basis for this attack,
> are they not?
Yes, but not only the usernames. Right now, also the users' full names
and home directory names are being used. In the future and with
non-Unix password files, other user-specific information may be used as
well.
It would be more correct to say that this is about "personally
identifiable information". This is a bit too restrictive, too, but in
the absence of better suggestions it could be good enough. Now, would
"PII mode" and --pii sound good?.. Alternatively, should the option
be --personal?
http://www.google.com/search?q=%22personally+identifiable+information%22
http://en.wikipedia.org/wiki/Personally_identifiable_information
The Wikipedia article says:
"In information security and privacy, personally identifiable
information or personally identifying information (PII) is any piece of
information which can potentially be used to uniquely identify, contact,
or locate a single person.
...
Information that is not generally considered personally identifiable,
because many people share the same trait, include:
* First or last name, if common
..."
So it's not the most appropriate name for this cracking mode. It is
useful to try even a common first name against a given password hash if
that's the name that is somehow associated with the account.
Other suggestions are welcome.
On renaming the "incremental" mode:
> > "bruteforce" (or "brute-force", or "brute force") is being used to refer
> > to so many different things that the only way to avoid the ambiguity is
> > to avoid using this buzzword entirely.
>
> Point taken. How about stat(istical)-attack?
It's better, but it does not highlight another important property of
this cracking mode: that it can potentially try _all_ possible candidate
passwords.
When ElcomSoft released a product called PWSEX (which has since been
renamed), I briefly thought of renaming "incremental" to "smart
exhaustive key search" (or "statistical exhaustive key search"?), for
--smart, --seks, or --sex (Smart EXhaustive) as the command-line option.
There's a company that already uses the term "smart force", though, to
refer to something similar but different:
http://lastbit.com/rm_smartforce.asp
apparently, their "smart force" will terminate after trying word-like
strings rather than search the keyspace exhaustively ordering candidate
passwords for decreasing estimated probability like John does.
Also, I've been considering adding a "dumb" mode which would search a
keyspace sequentially (this is what some other password cracker programs
call "brute force"). The rationale would be to get slightly higher c/s
rates for really fast hashes (such as LM hashes) in those rare cases
when a keyspace is actually meant to be searched exhaustively and it is
somehow not desirable to get some passwords cracked early on. It would
also permit for fair c/s rate comparisons against "competing" crackers.
And it would satisfy the demand for trying passwords consisting of
particular character sets that do not match the provided .chr files,
without having to generate custom .chr files out of fake john.pot's
(even though most of the time such requests are misguided).
If I do implement this, would it be --dumb, --deks, or --dex?..
Better suggestions are welcome!
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
