[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 06 May 2015 12:37:01 +0200
From: Frank Dittrich <frank.dittrich@...lbox.org>
To: john-dev@...ts.openwall.com
Subject: Re: John core: --format=crypt rejecting descrypt hashes
when it first found some bfegg hashes
On 05/06/2015 12:05 PM, Solar Designer wrote:
> 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.
No problem, I know you are extremely busy.
> 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?
That's on Fedora 20 (soon reaching end-of-life) with libc version: 2.18
and on Fedora 22 Beta 3 (all packages upgraded recently) with libc 2.21.
I would expect Fedora 21 to behave like Fedora 20 and 22, but cannot
test this.
> 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.
Agreed. This is better than silently ignoring the problem.
But if you load bfegg hashes first and then valid descrypt hashes, john
reports that no valid hashes were found. This might be a problem.
> 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.
Yes, that's a reasonable approach.
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.
