[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Dec 2011 01:51:45 +0100
From: Didier Arenzana <darenzana@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: cracking RADIUS shared secrets with john the ripper
Hi Jim, and thank you for your comments.
On Tue, Dec 6, 2011 at 1:19 AM, JimF <jfoug@....net> wrote:
> Using set_salt() vs salt() to do the HEX->binary conversion causes this to be done each time, for each password. If we can do this in salt, it is only done one time, at startup.
I had suspected this at one time, but when testing with gdb and the
following line, which I have intentionnaly modified so the hash is
'unsolvable' :
crack:$dynamic_1008$af25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e28e0409b2e2f3ab
seting a break point to dynamic_fmt.c:set_salt, I have seen set_salt
is called 3 times with the $HEX$ salt (and 48 times with the example
that is listed in the relevant section in dynamic.conf), and after
that john is runing uninterrupted; so I assumed it was ok. Maybe this
is due do the fact that I use dynamic_>1000 as opposed to the
internals dynamic_n formats ?
> However, the caveat here is, 'can' these salts contain NULL bytes? If so, then we either have to do the work like you have it done, or have the salt returned be like a Pascal string (length prepended to the string of bytes). Other than this 'possible' change, I think this addition to dynamic is good.
The salts used in the RADIUS protocol, which is why I wrote the patch
can and do contain NULL bytes, unfortunately. Is this pascal string
format already taken into acount in other parts of john ? in other
words, If I change the patch to use salt() and return a pascal string,
are there other changes needed than in the salt() and valid()
functions ?
> I do believe we will need to make changes in the 'length' computation parts (in valid I believe), which causes hashes to be set as invalid if lengths of things are too much (such as salt length). This computation should be done POST hex2bin, so that these salts would only be properly counted as 16 bytes, even though they take up 36 bytes in 'string' format.
I did not bother to change the valid() function, because using
dynamic_>1000, I did not specify a fixed length so I expected that it
would not cause trouble. And anyways, I could even have specified in
the config file a fixed len of 4 (the size of HEX$) + double the
length of the salt, to pass the check.
> once this is added, we could add $HEX$hex_salt to any salted format, and it should be 'happy' with it.
I might modify the patch later to comply with this, for now this patch
fulfill my needs I guess (except if I'm wrong on the set_salt vs salt
part). Of course, if anyone wants to improve the patch by applying
your suggestion, I have nothing against it .
>
> Jim.
Didier.
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.
