[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Aug 2020 10:40:54 -1000
From: Owein Douard <yvain29@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: rain mode
Hi again, my tests results are not good if it is to show which of -inc or
-rain mode cracks the most passwords in the shortest timespan.
My lists of hashes are full of these passwords that you managed to predict
with your method.
Yet some of them will not appear (on a 30 minutes run) with -inc and do
when using my mode.
The point is that -rain should be defined as a 'hardcode/complex passwords'
cracker, meaning unrealistic passwords or left out of -inc or markov logic
which,
when using a password manager or a piece of paper, are used. I desire to
see this method included in john and using opencl, so that we could run it
against lists of uncracked hashes from
temp.hashes.org, and am certain that many of them would be found.
I am ready to dedicate myself to this provided you can give me hints on
some parts of the architecture of john which are unclear to me.
If you need to do a comparison i suggest that we do so against the subsets
module, which resembles slightly rain and is only two times faster.
On Fri, Aug 28, 2020 at 4:43 AM Solar Designer <solar@...nwall.com> wrote:
> Owein,
>
> Thank you for this additional detail.
>
> On Fri, Aug 28, 2020 at 04:13:05PM +0200, Owein Douard wrote:
> > Alexander, to answer your question that is why and when to use rain mode,
> > I'd say after incremental mode has been run with a maximum length bound
> > that allows a full ascii character set to be exhausted.
>
> That's not how incremental mode is normally used, except sometimes for
> some short lengths where an exhaustive search can be done quickly.
>
> Normally, incremental mode is allowed to switch lengths back and forth,
> and doesn't exhaust the full ASCII character set for the higher lengths
> (several of them) that it ends up testing.
>
> > Then we should try this mode
> > starting with the latter run's maximum length + 1. This would avoid
> > duplicating.
>
> There wouldn't be that clear "maximum length + 1" in optimal usage of
> incremental mode, however let's suppose we crippled incremental mode
> (such as for ease of our further reasoning) by limiting it to some lower
> maximum length. Say, we let it run for lengths up to 6 and exhaust that
> space. Then we can either let it run for lengths 7+ or run rain mode
> for lengths 7+ instead. Either of these won't be limited solely to
> length 7 until exhausting it, but would try various passwords of length
> 7 and above. Which one of these would crack more passwords in the same
> amount of time? Can you test? My bet is on incremental.
>
> BTW, you don't actually need to exhaust length 6 to test the above - we
> only need password counts for length 7+ for one mode vs. the other. So
> you can only do the length 7+ tests, and we'll have our comparison.
>
> Please feel free to suggest and test this for another reasonable length
> threshold as well.
>
> > In general, the rain mode is not meant to be used against 'laid back
> > passwords', where users did not really care about their security because
> > they were eager
> > to access the service or wanted something easy to remember, but against
> > complex keys that are utterly unpredictable.
>
> > I am going to do these tests you asked for in a few hours from now and
> will
> > let you know, but my hashes are simples and you should expect incremental
> > mode to be the winner, but rain mode to find the long passwords before.
>
> Please feel free to also test on the kind of hashes where you expect
> rain mode to help. For example, you may take a list of mostly "laid
> back passwords" (in your words) like RockYou and leave only the unique
> passwords (not seen in there more than once).
>
> > I wrote a post on the forum of hashcat where I was introducing zhou as a
> > 'last resort cracking utility', and that is how the combination of the
> > algorithm and of the alternation of all the lengths should be used.
>
> Found it:
>
> https://hashcat.net/forum/thread-9298.html
> https://github.com/hashcat/hashcat/issues/1984
>
> > It's rare (for what I've seen) to find a truly long password, but when
> it's
> > the case, even though it be a simple one, the fact that we need to
> exhaust
> > the length one by one will make the task impossible,
>
> Incremental mode doesn't need to exhaust the lengths one by one.
>
> > Regarding the algorithm itself, I think it can fill a gap between a very
> > deep markov and a linear bruteforce.
>
> I think incremental mode already fills that gap.
>
> > Patterns that appear are once simple
> > once complex, I have not found any other way to express that than calling
> > it rain,
> > but maybe the word skyzo (skyzo = shattered) suits.
> >
> > Regarding the 3d note you made, the only thing that can be done to
> > randomize the algorithm is to randomize the starting value for the
> variable
> > 'rain', and wrap around the total expected, starting back to zero. It
> works
> > well. I tried it before.
>
> OK.
>
> Thanks,
>
> Alexander
>
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.
