[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150506100533.GA31539@openwall.com>
Date: Wed, 6 May 2015 13:05:34 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: John core: --format=crypt rejecting descrypt hashes when it first found some bfegg hashes
Frank,
I'm sorry your john-users posting slipped through the cracks here.
IIRC, I intended to look into it, but never went back far enough in my
stack of e-mails.
On Wed, May 06, 2015 at 10:16:43AM +0200, Frank Dittrich wrote:
> when john --format=crypt loads bfegg hashes first (length 13), it
> doesn't recognize valid descrypt hashes anymore.
I am not able to reproduce this. What libc (and version) has its
crypt() refuse to process invalid descrypt salts, yet includes descrypt
support for valid salts? (FWIW, recent OpenBSD dropped descrypt
altogether. But that's different.)
Invalid descrypt salts have historically been supported in libc's, in at
least two different ways. (And this is a reason why someone might in
fact want to use --format=crypt on descrypt hashes: we support only one
of 2+ ways in our own descrypt code.) I think it's almost a libc bug to
break this tradition now (short of dropping descrypt support
altogether). Anyway, we might in fact choose to workaround it, if such
libc's are present.
> Test with valid non-descrypt hashes and invalid bfegg hashes:
>
> (master)run $ ./john hashes.aix-smd5 hashes.bfegg
> --wordlist=password.lst --format=crypt
> Warning: hash encoding string length 37, type id #0
> appears to be unsupported on this system; will not load such hashes.
> Warning: hash encoding string length 13, type id #1
> appears to be unsupported on this system; will not load such hashes.
> Loaded 3 password hashes with 3 different salts (crypt, generic crypt(3)
> [?/64])
> Self test failed (valid)
While this looks extremely weird at first, arguably this behavior
actually makes sense. It's a failure of libc's descrypt support, and
it's being reported to the user rather than ignored.
> If you switch the sequence, i.e., load descrypt first, then bfegg, all
> these hashes are considered valid, but later on you get a
>
> Warning: crypt() returned NULL
Ditto.
The heuristic to detect what's valid and what is not during hash loading
and with minimal CPU time wasted can't be perfect. crypt()-testing
every hash being loaded would result in slow load times, which is why we
use heuristics.
Something like Jim's patch makes sense to me, but I am not sure.
Regarding your other example with:
?:CCNf8Sbh3HDfT
?:CCNf8Sbh3HDfS
?:CCNf8Sbh3HDfR
?:CCNf8Sbh3HDfQ
It's expected behavior that --format=descrypt recognizes and skips the
invalid ones of these hashes while --format=crypt loads all of them (as
long as descrypt hashes are supported on the system). --format=crypt
isn't supposed to be overly-aware of individual hash types. Not a bug.
Thanks,
Alexander
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.
