[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77900a69c8ef70cf0874bc892e0f3a26@smtp.hushmail.com>
Date: Mon, 19 Nov 2012 08:22:44 +0100
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: cracking passwords with a kerberos traffic dump / aes256-cts-hmac-sha1-96 (18) [MS]
On 18 Nov, 2012, at 11:15 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
> On Sun, Nov 18, 2012 at 3:06 PM, magnum <john.magnum@...hmail.com> wrote:
>> On 18 Nov, 2012, at 9:00 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
>>> On Sun, Nov 18, 2012 at 6:59 AM, buawig <buawig@...il.com> wrote:
>>>>> As in standard Kerberos? It would surprise me a whole lot if
>>>>> Microsoft do not use the Unicode version of the password, or (even
>>>>> more likely) the 16 byte NT hash as input just like in mskrb5, as
>>>>> opposed to the plain string you use now.
>>>>
>>>> Ok, this makes it clear why I was not be able to crack it. So the
>>>> outcome will be a MS specific john format (mskrb5-18).
>>>
>>> I don't think that it is necessary to modify krb-ng_fmt_plug.c to
>>> support M$ AD specifically as M$ AD follows RFC.
>>
>> Does the RFC specify how to encode the password? Is the known plaintext string included in the RFC?
>
> RFC doesn't mention UTF anywhere it seems . Test vectors are included
> in https://tools.ietf.org/rfc/rfc3962.txt
One of the test vectors does include a g-clef in UTF-8. This is even outside UTF-16 (U+1D11E):
http://www.fileformat.info/info/unicode/char/1d11e/index.htm
The fact they use UTF-8 is good and bad: It's good because existing code will work fine without "handling" Unicode in any way. It's bad because it will only work with UTF-8 input - eg. using --encoding=iso8859-1 will not help if you feed it an ISO-8859-1 wordlist, it will only crack ascii passwords.
There are ways to handle this but I'm not sure how to proceed. SAP F/G is similar, it always uses UTF-8. It will currently just emit a warning unless run with UTF-8. For a while it actually converted any codepage -> UTF8 within the format. Maybe we should support this in core, after the rules engine. I have played with the thought of adding a --hashed-encoding option or something like that (it would be handy for LM too). Or maybe we should do that in-format conversion for these two formats (and probably more, like XSHA and others) using a shared function.
Anyway, your current code must *not* set FMT_UNICODE nor FMT_UTF8.
magnum
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.
