[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Nov 2015 08:49:35 +0100
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: password cracking as a subset of hash searching
On 2015-11-20 08:23, Frank Dittrich wrote:
> On 11/20/2015 08:09 AM, Royce Williams wrote:
>> In this blog post:
>>
>> http://roycebits.blogspot.com/2015/10/hash-filtering-more-than-vanity.html
>>
>> ... I argue that password cracking frameworks should start to
>> incorporate searching for partial matches of hashes -- vanity hashes,
>> partial collisions, hashes that mask specific masks, etc.
>>
>> In other words, I see password cracking (searching for hashes that
>> exactly match known hashes) as part of a larger class of activities
>> (searching for hashes with specific properties), and see potential for
>> cross-pollination with related work that would ultimately benefit the
>> project. I point out some recent examples in the post.
>
> If you are just interested to have a certain string in your hash, why
> not just provide an appropriate salt when computing that hash?
> Since the salt needs to be encoded in the hash, you can be sure that
> string will be part of the hash, no matter what password you use.
> OTOH, this will increase the risk of hash collisions, i.e., an attacker
> can crack 100 hashes with 0xdeadbeef as a salt at the cost of just one
> regular hash.
Good point (when applicable). Here's a vanity hash made like that
(without any effort).
$1$magnum$BNjJ6SLD6nzJ9fvtI39up.
For hashes (like this one) where the salt is listed first, not doing it
that way would be "worse" since it would have the vanity string later in
the hash, eg. (mockup):
$1$xIjJ34.K$magnumEoTBMFvt8Gr2Y.
OTOH you could obviously do both (also mockup):
$1$magnum$ripperXfdW/4KTb6rz4kZ/
magnum
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.
