[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABtNtWFvRXM1XC4CTvbLHcQ7VMz62HD1K_uRm54-OnuRZ1t8Hg@mail.gmail.com>
Date: Fri, 6 Mar 2015 18:30:04 +0800
From: Kai Zhao <loverszhao@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Generic crypt(3)
Hi Alexander, thank you very much for the prompt and detailed reply.
It helps me a lot.
Kai
On Fri, Mar 6, 2015 at 6:17 PM, Solar Designer <solar@...nwall.com> wrote:
> On Fri, Mar 06, 2015 at 05:28:08PM +0800, Kai Zhao wrote:
> > The right-format one took a lot of time and I canceled. The changed one
> > took a lot of time too. I think
> > the changed one is wrong-format. Since there is a character "???" .
> crypt(3)
> > man page shows that the
> > format should be : "$id$salt$encrypted". Also the characters in "salt"
> and
> > "encrypted" are draw from
> > the set [a-zA-Z0-9./];
> >
> > However, john did not recognize the changed one as wrong-format and tried
> > to crack it.
> [...]
> > Is this a bug?
>
> No, not a bug, because the generic crypt(3) format is special. Its
> primary purpose is to support whatever hash types the underlying system
> might support, even if those are not known to JtR. While we could
> special-case sha512crypt - and in fact, we do have some special-case
> logic to handle it more optimally already - we're not expected to do
> that, and in fact we can't do it for hash types that we're not yet aware
> of (that might appear and be introduced into a system's crypt(3) in the
> future). So we can't fully patch the behavior you observed to ensure
> that an invalid hash encoding would never be loaded by the generic
> crypt(3) format.
>
> For other JtR formats, this sort of behavior would most likely indicate
> a bug that we could patch. So please keep searching! For example, will
> your wrong-format hash be loaded by jumbo's sha512crypt,
> sha512crypt-opencl, or sha512crypt-cuda formats? If so, that's a bug
> that we should patch. Please test and let us know.
>
> Regarding the special-casing I mentioned, right now c3_fmt.c does it to
> determine the salt length for the hash types it's specifically aware of.
> This allows JtR to detect matching salts for those. If a yet unknown
> hash type is processed by c3_fmt.c, detection of matching salts would
> not work for that hash type - but other than that, passwords would be
> tested against those hashes correctly anyway.
>
> We could extend the special-casing so that we also validate the encoding
> of the entire hashes. So far, we haven't bothered to do that, and I'm
> not sure if we should. Like I said above, I think this is not expected
> of the generic crypt(3) format. But it would not hurt to have this
> extra either, except in terms of code complexity. So I think this is a
> topic we may revisit if/once we get some generic hash encoding
> validation function into JtR (regexp match alike), which is something
> Alexander Cherepanov was/is proposing. We might introduce this sort of
> function to simplify and make more reliable the valid() methods in other
> formats, and if/once we do I would not mind us using it in the generic
> crypt(3) format as well (obviously, only for the crypt(3) hash types
> we're aware of at a given moment).
>
> BTW, it's crucial not to be too strict. We need to accept invalid salts
> that could be in use somewhere in practice. For example, you wrote:
>
> > format should be : "$id$salt$encrypted". Also the characters in "salt"
> and
> > "encrypted" are draw from
> > the set [a-zA-Z0-9./];
>
> While ideally JtR should not load for cracking hash encodings where the
> hash encoding itself is impossible (the wrongly-named "encrypted"
> portion above), because it'd never get a match for those, it should
> nevertheless load those where the salt portion uses invalid characters,
> if there exists a defensive-use implementation that would accept such
> invalid salts (and process them in some specific way, which JtR should
> mimic).
>
> For example, JtR takes specific care to process invalid salts for
> descrypt in the same way as certain defensive implementations do
> (although there are also other defensive implementations that process
> invalid descrypt salts differently; there's room for improvement here).
>
> Another curious detail is that while the specification you quoted above
> allows for any of the 64 characters from [a-zA-Z0-9./] to be used in any
> character position in the actual hash encoding (the "encrypted"
> portion), in practice the very last character usually encodes fewer bits
> from the binary hash value, so fewer different characters are possible
> in the last character of the encoding. Again, JtR's descrypt formats'
> valid() is aware of this, imposing this extra restriction (and thus not
> loading for cracking some valid-looking but actually impossible
> 13-character strings). The same should apply for sha512crypt and
> sha256crypt, since neither 512 nor 256 is a multiple of 6, but I don't
> think our existing sha{256,512}crypt* formats' valid() functions are
> currently aware of this detail. We could enhance them in this respect.
>
> Thanks,
>
> Alexander
>
--
loverszhaokai
motto：You got a dream and you gotta protect it.
github：https://github.com/loverszhaokai
blog：http://www.cnblogs.com/lovers/
Content of type "text/html" skipped
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.
