[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFs9wnWAkY1djVCbVG4JBkcafcj1uMxVLo6ELhw_iGqb=U6ZBQ@mail.gmail.com>
Date: Sun, 21 Mar 2021 10:53:39 +0100
From: Michał Majchrowicz <sectroyer@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: password patterns (was: Multi-gpu setup)
> I suggest you don't "book time on more modern hardware to speed the test
> up", but instead use a faster and unsalted hash type, then scale your
> attack duration to your target scenario by the observed p/s figures.
I want to check how it will deal with 2 passwords I don't know but
already narrowed down what they can be. Also if I use different hash
type I won't be able to (easily) compare with results I already
obtained by manually "trimming" keyspace.
> I'd recommend testing on many more hashes, but I don't know if you can
> obtain many more matching your criteria (from IoT devices?)
I think I will have to generate those myself. At the moment I have
about 40 hashes that I have gathered from different IoT devices.
Nevertheless not all are useful for this test. Let me explain. Some
IoT manufacturers (like Smart TVs) don't bother with making complex
passwords. They are often same for different models for years. It's
understandable as often user doesn't even have any access to shell so
how complex password is doesn't change much in terms of security.
There is however strange exception - IP Cameras. For some strange
reason most of them either have telnet enabled by default or it's easy
to enable it. Moreover user doesn't have credentials and can't even
access "a backdoor" that manufacturer put in. We noticed that mostly
two hashing algorithms are used: descrypt and md5crypt. Since md5crypt
is significantly slower and doesn't have upper character limit (I
don't count 4096 ;)) those passwords follow different (usually simpler
rules). In case of descrypt I noticed 3 groups of passwords. Part of
hashes that I have collected are simple stuff that you often don't
need a dictionary: "root", "admin", "linux", "" (empty pw). Part are
passwords that are just variations of dictionary words that
dict+best64 cracks without any issues and last part are passwords
where manufacturers knew about disadvantages of using descrypt and
tried mixing capitalisation, adding special chars etc. From this last
group I have around 10 hashes (depends what you "count in" :)). To be
honest I don't understand why they didn't move to md5crypt directly...
Also I think I didn't explain my "ai idea" correctly. I didn't want to
use to generate rules for samples I know but on the basis of existing
patterns generate new ones for hashes I don't know(just "guessing"
which patterns they might have). Anyway please take into consideration
that all of this is preliminary assumptions which require more
research. Some of them will be wrong but point is in gathering more
data and coming with conclusions after that :)
> Incremental mode follows patterns seen in the passwords it was trained
> on. The supplied .chr files were trained on RockYou. If your patterns
> are similar, they should work well. If your patterns are very
> different, you'll need to re-train on those for it to work well.
That's what I want to check and what I fear is the issue. Training at
the moment would be hard as I don't have many of those hashes. I think
I first would have to generate some pseudo-random set.
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.
