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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ