Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ