[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130202151250.GA22653@openwall.com>
Date: Sat, 2 Feb 2013 19:12:50 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: NTLMv1 and MSCHAPv2
On Fri, Feb 01, 2013 at 11:10:48PM +0100, magnum wrote:
> On 1 Feb, 2013, at 19:48 , magnum <john.magnum@...hmail.com> wrote:
> > BTW when I implemented that, I was wondering if we could not add a late-reject for these cases: If binary() returns NULL we got a late reject. Would it be too late to efficiently handle that in loader?
>
> Only after fixing the above, I went on with this. This trivial patch works like a charm:
Didn't you say you implemented the 3rd DES block cracking in valid()
first? Do you feel late-reject on binary() is somehow cleaner? Yes,
this lets you avoid the caching from valid()...
> Solar, are you OK with this? I will add it to bleeding and start actively using it. I know we have formats that detect late rejects in binary() but can't do anything about it other than make it safe (an uncrackable hash is added) or abort (not a good solution). This can arguably always be fixed in valid() but sometimes this is really impractical or expensive.
I think the late-reject in binary() will have side-effects. I can think
of one off the top of my head:
When valid() returns non-zero, we detect the format. Then if binary()
of that format returns NULL for this and for all further strings, we end
up with nothing loaded at all, whereas with the reject in valid() we
could have possibly detected another format (for the same or for other
lines in the file).
So this doesn't look like a cleaner solution than having the expensive
checks and caching in valid(). We'll probably have to add yet another
(complicated) answer to the FAQ entry on "No password hashes loaded".
I don't like this hack, yet I don't mind having it in jumbo if you like it.
Oh, here's an idea: maybe your patch to the loader could handle the
special case I explained above? If valid() returned non-zero, but the
format was not previously detected, set a flag (just an int variable
local to the loader). Then if binary() returns NULL and the flag is
set, "undetect" the format and probe other formats' valid() methods for
this line and (if still not detected) for further lines, like it's done
normally. If binary() returns non-NULL, then the format is detected for
real and the flag should be reset. (Need to take a look at the code to
determine if an extra flag variable is actually needed, or maybe these
conditions can be inferred from the variables we already have.)
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.
