Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Sep 2015 11:31:22 -0500
From: JimF <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: auditing our use of FMT_* flags


On 9/11/2015 11:15 AM, JimF wrote:
> Just did a quick check.
>
> This hash:
>
> "$K4$e35e9294ecef926d,0123", "U*U*U*U*"
>
> binary() returns this e35f9395edef936d00480008
>
> My code can not find the binary string in the original hash, so no 
> work is done.  The format binary size is 12. Nowhere in the hash is 
> there a 24 byte long hex string to start with.
>
Note, if the salt was hex encoded, then the 2nd change I made, to also 
try to find hex encoded salts, would have found the problem. However, 
this format has 'actual' salt storage. Btw, how to we handle salts with 
':' in them??

But all the logic I am using does, is to try to find some 'known' hex 
values in the hash.  If you can think of a better way to detect these 
hex items that would do this without ANY knowledge of the underlying 
format of the hash, then I am all ears.  But the code can not wildly 
change case, because there is framing text, base-64, etc that if you 
change that, the entire process is invalidated. However, 'tricks' we are 
using in john code certainly will cause this code to not be able to 
detect all problems. Things like having the last few steps of the 
algorithm being skipped, and binary() returning this 'per-completion' 
state will not allow the logic to find this string, since the hash has 
the fully completed result, not the shortcut partial completion.  Other 
adjustments to the return data from binary can also cause the code to 
not find it.   However, a 'short' return in binary will allow the string 
to be found, HOWEVER, it can also have a 'false' positive potential. Say 
binary only returns 1 byte.  Then if that 2 byte hex value is found in 
the hash, it will be treated as a match, even if it is not.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ