[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060119194432.GA17630@openwall.com>
Date: Thu, 19 Jan 2006 22:44:32 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Incremental Alpha Quagmire
On Wed, Jan 18, 2006 at 02:58:40PM -0800, Arias Hung wrote:
> [Incremental:Alpha]
> File = $JOHN/alpha.chr
> MinLen = 8
> MaxLen = 8
> CharCount = 26
>
>
>
> What is baffling to me is the charcount, since it's listed as only 26
That's how many different characters alpha.chr has. Perhaps it's
misnamed, it should have been called lower.chr. (The name alpha.chr is
more correct for case-insensitive hash types, though.)
> yet alpha passwords seem always to be a mixture of upper and lowercase.
Actually, no, all-lowercase passwords are more common in practice,
unless the target system enforces a policy prohibiting such passwords.
> Should not the character count be 52?!?!
No, not here. Maybe I should be providing a pre-generated .chr file for
mixed-case letters, although I think that all.chr is usually more
reasonable to use if you're going to be trying uppercase letters at all.
> Also, it seems to take an exorbitant amount of time before john begins
> attempting mixed (upper + lower) Alpha combinations.
It would never do that with alpha.chr. You need all.chr for that. And,
no, it does not take too long until it tries some uppercase letters in
some character positions with all.chr. Of course, it won't be trying a
lot of uppercase early on, -- because those characters are significantly
less common in passwords than lowercase ones.
> What would be the ideal way to get the upper/lower combinations to begin
> immediately?
Use all.chr. If you really want uppercase letters to be treated as if
they were as common as lowercase ones, you can define an external mode
or generate a custom .chr file from a fake john.pot. But your success
rate will be lower.
> Wouldn't it be ideal to increase character count to 52
The "CharCount" setting is mostly just a comment. If you increase it to
52 without substituting another .chr file, John will give you a warning
that "only 26 characters are available".
Yes, you may generate a new .chr file with lowercase and uppercase
letters. You'd need to define the appropriate external filter() (to use
when generating the .chr file) and you need to have all those characters
already in your john.pot (or you can use "Extra = ..."). Once again,
the resulting .chr file will likely yield a lower success rate (at
cracking passwords which you did _not_ already have cracked by the time
you generate the .chr file) than the provided all.chr does.
> and consider upper and lower to be separate character types
They are indeed considered as separate, for hash types which treat
passwords as case-sensitive.
> as they certainly are treated as distinguished from one another as all
> passwords are case sensitive?
This is true for all Unix passwords, but not for all hash types
supported by John. Windows LM hashes are case-insensitive.
--
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
Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.
