[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230423184241.GA20610@openwall.com>
Date: Sun, 23 Apr 2023 20:42:41 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: bcrypt $2y in target list written as $2a in potfile?
Hi Royce,
On Sun, Apr 23, 2023 at 09:45:33AM -0800, Royce Williams wrote:
> For at least hashes for me, bcrypt $2y from a specific target list are
> being written as $2a in my john.pot.
>
> I was running an older GitHub jumbo, so I pulled latest jumbo:
>
> John the Ripper 1.9.0-jumbo-1+bleeding-3ba3a5462 2023-04-22 20:33:04 +0200
> OMP [linux-gnu 64-bit x86_64 AVX AC]
>
> ... and the behavior is the same. What might cause this? I thought the
> difference was in the pre-processing of the original plaintext prior to
> hashing, with no change in the hash format (other than the $2a type change).
This is our unification on writes to john.pot working as intended. See:
https://github.com/openwall/john/issues/4769
We can see how this can be confusing, but the alternative was
differently confusing and problematic. It's with several hash types
(not only bcrypt) that we have to perform some unification (or in some
cases even splitting the hashes in half, such as for LM and bigcrypt)
when storing them in john.pot to avoid other subtle issues and
limitations. Overall, there's no guarantee that john.pot contains exact
and complete hashes for the cracked passwords. Instead, you're supposed
to use "john --show" to have proper and reliable matching of your hashes
to what's been cracked. Makes sense?
The even more subtle issue fixed by this unification for bcrypt was:
https://github.com/openwall/john/issues/4388
As you can see in there, we also "Replace potential invalid salts with
their valid counterparts" for descrypt.
This is not ideal. Thinking of it now, maybe we could instead perform
unification on loading of hashes from both input files and john.pot
instead (so that we'd have a match on "john --show" and on detection of
already-cracked hashes at loading like we do now) even when neither is
pre-unified. This would be slower (need to do it twice per input line,
not once), and you'd still need to use "john --show" to see all matches
(or otherwise a previously-cracked but differently-encoded hash would
appear uncracked to your manual or scripted matching against john.pot).
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.
