Date: Wed, 6 May 2015 13:05:34 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: John core: --format=crypt rejecting descrypt hashes when it first found some bfegg hashes Frank, I'm sorry your john-users posting slipped through the cracks here. IIRC, I intended to look into it, but never went back far enough in my stack of e-mails. On Wed, May 06, 2015 at 10:16:43AM +0200, Frank Dittrich wrote: > when john --format=crypt loads bfegg hashes first (length 13), it > doesn't recognize valid descrypt hashes anymore. I am not able to reproduce this. What libc (and version) has its crypt() refuse to process invalid descrypt salts, yet includes descrypt support for valid salts? (FWIW, recent OpenBSD dropped descrypt altogether. But that's different.) Invalid descrypt salts have historically been supported in libc's, in at least two different ways. (And this is a reason why someone might in fact want to use --format=crypt on descrypt hashes: we support only one of 2+ ways in our own descrypt code.) I think it's almost a libc bug to break this tradition now (short of dropping descrypt support altogether). Anyway, we might in fact choose to workaround it, if such libc's are present. > Test with valid non-descrypt hashes and invalid bfegg hashes: > > (master)run $ ./john hashes.aix-smd5 hashes.bfegg > --wordlist=password.lst --format=crypt > Warning: hash encoding string length 37, type id #0 > appears to be unsupported on this system; will not load such hashes. > Warning: hash encoding string length 13, type id #1 > appears to be unsupported on this system; will not load such hashes. > Loaded 3 password hashes with 3 different salts (crypt, generic crypt(3) > [?/64]) > Self test failed (valid) While this looks extremely weird at first, arguably this behavior actually makes sense. It's a failure of libc's descrypt support, and it's being reported to the user rather than ignored. > If you switch the sequence, i.e., load descrypt first, then bfegg, all > these hashes are considered valid, but later on you get a > > Warning: crypt() returned NULL Ditto. The heuristic to detect what's valid and what is not during hash loading and with minimal CPU time wasted can't be perfect. crypt()-testing every hash being loaded would result in slow load times, which is why we use heuristics. Something like Jim's patch makes sense to me, but I am not sure. Regarding your other example with: ?:CCNf8Sbh3HDfT ?:CCNf8Sbh3HDfS ?:CCNf8Sbh3HDfR ?:CCNf8Sbh3HDfQ It's expected behavior that --format=descrypt recognizes and skips the invalid ones of these hashes while --format=crypt loads all of them (as long as descrypt hashes are supported on the system). --format=crypt isn't supposed to be overly-aware of individual hash types. Not a bug. Thanks, Alexander
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.