[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <392C5EE3C1924C408B593FC9864ACB75@D9VGLK61>
Date: Sun, 4 Dec 2011 16:48:39 -0600
From: "JimF" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: Re: cracking RADIUS shared secrets with john the ripper
> Hi,
> I am currently working at using john the ripper to audit RADIUS shared
> secrets, using network captures as input.
>
> RADIUS relies on MD5 to protect passwords; for attack 3.3 I have been
> able to use format 'dynamic_1' (joomla), which implements md5($p.$s) :
> Here, the salts are
> string of 16 bytes that can be of any value. So I wrote a patch to
> function 'set_salt' in dynamic_fmt.c
We have needed something like this for a while. I would also like to 'eliminate' the non-colon option, that we see in dynamic_7, and use a hex salt instead.
> that does the above: if the salt
> begins with the string 'hx', then it expects it in base16 format, and
> converts it. (it appears there is also a maximum length for the salt
> in the file, so I could use 'hx', but not 'hex' for the prefix).
Hmm, I thought max salt length was longer. It may have limitations for some formats, due to elimination of overflow. For SSE builds of john, we can not have a string longer than 55 bytes that is encrypted (at the current time). This limitation has been partially relaxed, and may be 'fully' relaxed at some near future time. It is likely that this format has a max salt length set to avoid any possible overflow, and still allow a 'decent' length password to be tested. The dyna does not know that a hex salt is (len-2)/2 so if we implement this for 'real', the salts you have would only count as 16 bytes.
I think $dynamic_n$hash$HEX$hex_salt would be my preferred method to host a hex salt. This way, the only way we could get a 'blown' salt, is if HEX$ was the first 4 characters of the salt. Pretty unlikely. However, a salt starting with hx is not unlikely.
> I
> have been able to use it successfully with my own-generated test
> capture files, and john found a trivial shared secret almost
> instantly.
>
> So here comes my first question : Is there a better solution than
> using this patch ?
Not that I can think of. This would require some form of custom code to make it work.
> I'd be happy to share the patch and the perl script
> with the community, but I want to check first if there is a better
> solution.
>
> I will now try to implement attack 3.1, and I have already written a
> dynamic format in john.conf to handle md5($s.$p) ; and I have another
> question : the salt being first in the concatenation, will john be
> smart enough to pre-compute the MD5-state for salt, and apply it to
> all the candidate passwords?
No, there is nothing that can be 'pre-computed'. If the salt was 64 bytes, then we 'could' do some precomputation, but that would be about it.
If the format was md5(md5($s).$p), then we do have something in dynamic which will precompute the md5 for the salts, and this reduces the search to the same amount of time as a dynamic_0, raw md5.
> And, one last question: using this method results in password files
> with multiple times the same original password with different salts.
This is very 'normal'. This is why salts are used. So there is no way to pre-compute that 20 hashes that use different salts all have the same password. In all actually, there could be a single password for your entire set of hashes, and this would give you no indication at all, that only a single word crackes them all (until you find it).
> Is this of any use for john, or does it slow down the process of
> finding the password ?
Yup, standard reason why salts are used.
> (I believe the answer is the latter, but wanted
> to check with others). Should I restrict the output to one line per
> original password ?
John will handle all of this. If 10 hashes use garbage password of 123456, then each of them should show up cracked in john.pot, all with the same password.
Jim.
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.
