[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 27 Jul 2021 21:08:36 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking nested hashes with unknown salts
Hi David,
Once again, sorry for the belated reply.
On Sun, Jun 27, 2021 at 12:52:04AM -0700, David Sontheimer wrote:
> I'm curious if John can crack this second password generation heuristic as
> well (beyond incremental mode):
>
> A password that is the truncated hash digest of a hashing algorithm, with a
> known input (or wordlist of possible inputs), along with an unknown salt of
> known length and of a known character set.
>
> For simplicity's sake, let's call this a "hashword."
>
> A hashword is now salted and hashed as usual - for our experiments, using
> sha1_crypt - and written to file.
>
> For additional specifics, let's say the following for generating hashwords:
>
> 1. The hashing algorithm is sha256_crypt - but again, only the digest is
> known - the initial salt remains unknown, removed from the output.
> 2. The digest is truncated to a known length between 4-8.
> 3. The salt is of length 8, of the custom alphabet [lowercase letters] +
> the five digits [0-4] + the three specials [!@$].
In this example, the digest is truncated to a length lower than or the
same as that of the unknown salt. As a result, no one would be able to
confidently recover the original password - rather, there would be
multiple possible combinations of password and salt.
> I'm comfortable writing an external script for generating these candidates,
> and using John's --stdin option, but I'm curious if John can generate these
> hashword candidates internally with a wordlist and appropriate rules.
I'm not sure I understand your preference here, but from your
description it sounds like you'd reasonably first target the very short
digests, "truncated to a known length between 4-8", and only then work
towards combinations of original password and salt producing those. In
two separate JtR runs. And the second one will require a custom format,
because our existing sha*crypt formats wouldn't match partial hashes
(they would require full matches).
You can also do it all in one JtR run, such as to detect the weakest
passwords quickly, but again you would need a custom format
(implementing your two-hash algorithm) or preprocessing of the first
hash by a script (like you seem to imply when you mention --stdin).
> My goal is similar to the work done cracking pwdhash passwords using
> hashcat, as described here:
>
> https://www.flypig.co.uk/papers/dlj-gr-passwords16.pdf
>
> One difference is that pwdhash uses a website TLD as additional input,
> assumed to be known to the attacker; our hashword uses a client-side salt
> unknown to the attacker.
>
> I recognize incremental mode would eventually find the hashword. Yet I'd
> like to find the word and client-side salt used for initial input.
>
> I hope hashword generation makes sense. Please let me know if I've left out
> important details.
Sure you generally harden a master password scheme by also having a
random salt, which then needs to be backed up.
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.
