[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Dec 2011 00:33:42 +0100
From: Didier Arenzana <darenzana@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: cracking RADIUS shared secrets with john the ripper
On Sun, Dec 4, 2011 at 11:48 PM, JimF <jfoug@....net> wrote:
> Hmm, I thought max salt length was longer. It may have limitations for some formats, due to elimination of overflow.
Now that you mention it, i think the limitation was due to the
dyanimc_1 format used (joomla). I'll check implementing it with a
specific dynamic_1xxx format, using the config file.
> 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.
Understood, I will change my patch to work this way.
>> 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.
Yes, and if I have different users with the same password, it makes
sense; but what I was thinking is if I have different (salt, hash)
couples for the same "user" (in my RADIUS case, users are client
machines), hence the same password; it will uselessly slow down the
cracking process to store them all in the password file.
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.
