Re: Can Kerberos be cracked??

From: Bugger Bugtraq (somebug@hotmail.com)
Date: 10/24/01 

From: "Bugger Bugtraq" <somebug@hotmail.com>
To: larobins@bellatlantic.net, fp56@dial.pipex.com, focus-ms@securityfocus.com
Subject: Re: Can Kerberos be cracked??
Date: Wed, 24 Oct 2001 01:48:06 +0000
Message-ID: <F89Zu8VamThcdV2XlZ500005861@hotmail.com>

Assuming the steps on user verification u've stated is correct (I'm not
exactly into the details either)....firstly, wouldn't the hash (used to
encrypt the timestamp) still be susceptible to brute-force using dictionary
attacks (or even trying all possible combinations) especially since the
hashing algorithm is known. (maybe even consider maintaining a database of
pre-worked password-hash combinations)

Secondly, even without the actual password known, wouldn't juz the hash (let
say we have managed to get it as what u've stated below) be sufficient to
spoof the authentication (since that hash information is all that is needed
to encrypt the timestamp anyway)???

Did I get what u are saying rite?????

>From: "Laura A. Robinson" <larobins@bellatlantic.net>
>Reply-To: "Laura A. Robinson" <larobins@bellatlantic.net>
>To: "Phil Pinder" <fp56@dial.pipex.com>, <focus-ms@securityfocus.com>
>Subject: Re: Can Kerberos be cracked??
>Date: Mon, 22 Oct 2001 20:35:59 -0400
>
>Okay, first, looking at my response, it wasn't as clear as I would have
>liked, so let me clarify it.
>
>When Jim Bob Billy Joe logs in and types in his password, that password is
>run through a hash (hashing algorithm) to produce a string of bytes. The
>hash itself is non-reversible, which means that it cannot be used to derive
>the password. [*see note at bottom] The resultant set of bytes from the
>hashing of the password is, in this case, the key that is then used to
>encrypt the timestamp. When the KDC receives the preauthentication request,
>it retrieves the user's key (which is the result of the hash) and uses that
>to decrypt the timestamp.
>
>Where I feel I wasn't clear in my response was when I said that the
>"resultant hash" generates the encryption key, when what I should have said
>was that the "hashing algorithm" generates the encryption key and that the
>encryption key is then used to encrypt the timestamp. Apologies for my
>distinct lack of clarity; it was a rushed response. :-)
>
>Now, on to your question below- when a user's password is created or
>changed, the new password is hashed and the resultant value transmitted as
>the user's new "long-term" (stored in AD and encrypted) key. On the
>occasions when that key needs to be transmitted across the wire, it is
>transmitted using SSL over LDAP, thus protecting the key while it is in
>transit.
>
>Now, as for how the authenticating server verifies the password- it
>doesn't.
>It verifies the key. The server doesn't actually know what the user's
>password is, and doesn't care. What the server does know is what the hash
>result (key) is. When the server receives the preauthentication request, it
>retrieves the user's key from AD and decrypts the timestamp with that. If
>it
>can successfully decrypt the timestamp with the user's key and the
>timestamp
>has not expired, then the server knows that the correct key (hash result)
>was used to encrypt the timestamp.
>
>So, even if you *could* snag the correct packet off the wire and decrypt
>the
>timestamp (we're talking significant time here), all that would actually
>tell you is what the byte string was that was used to encrypt the
>timestamp-
>it wouldn't tell you the user's password.
>
>*note at bottom:
>
>by referring to the hash algorithm as non-reversible, think of it like this
>(none of this math is valid in any way or meant to represent the actual
>hashing algorithm; I'm just trying to conceptualize how a one-way hash
>works
>for those who might be unclear)
>
>I am your computer. (Obviously, I'm not, but bear with me. ;-) )
>
>You change your password to "jimbobbillyjoe".
>
>I take the word "jimbobbillyjoe" and say to myself, "Okay, I'm going to
>derive the key by counting the number of letters in the password (14), then
>adding five to that number (19). If the result is more than one digit in
>length, I'm going to multiply by five to get another number. If it is less
>than two digits, I am going to multiply it by forty-two. (Since result is
>19, it is multiplied by 5, resulting in 95.) Then I'm going to go through
>the alphabet as many times as it takes to gather the number of digits in
>the
>result number. (Therefore, I would go through the alphabet to produce the
>following:
>abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwx
>yzabcdefghijklmnopqrstuvw ) Then I'm going to take all of those letters and
>dump the vowels.
>(bcdfghjklmnpqrstvwxyzbcdfghjklmnpqrstvwxyzbcdfghjklmnpqrstvwxyzbcdfghjklmnp
>qrstvw). Then I'll assign numeric values to each letter in the alphabet,
>write out all the resulting digits, and that is what I will then use as
>your
>new long-term key."
>
>The point here is, you have no way of knowing exactly how the resultant
>value actually came to be, only what the resultant value (key) is, and you
>can't "undo" what I did to produce it. That key is what is used to
>(reversibly) encrypt the timestamp in your preauthentication data, and the
>key is the only thing that the KDC has associated with you- *not* your
>password itself.
>
>I hope this makes sense; I'm high on Nyquil due to having a case of the
>flu.
>
>Oh, and if you just want the quick and dirty answer to your question (now
>that I've looked at it again and realized you asked a very simple
>question):
>
>The encryption key itself is sent to the authenticating server when it is
>created (*not* when it is used to encrypt a timestamp), and it is protected
>by transmitting it via SSL over LDAP.
>
>Hope this helps,
>
>Laura Robinson
>
>----- Original Message -----
>From: "Phil Pinder" <fp56@dial.pipex.com>
>To: "Laura A. Robinson" <larobins@bellatlantic.net>;
><focus-ms@securityfocus.com>
>Sent: Friday, October 19, 2001 6:17 PM
>Subject: RE: Can Kerberos be cracked??
>
>
> > Thanks for the info Laura
> >
> > That raises the question: how does the Authentication server verify the
> > password - by generating the same encryption key? (in which case couldnt
>it
> > still be reverse engineered?) or is the encryption key itself sent
>encrypted
> > to the Authentication Server (encrypted with what key?)? (I cant find an
> > explanation at this level of detail without it resorting to
>cryptographic
> > algebra)
> >
> > Many thanks
> >
> > Phil
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Relevant Pages

  • RE: Can Kerberos be cracked??
    ... Subject: Can Kerberos be cracked?? ... If you were able to decrypt the timestamp ... As for your assumption about the hash being as good as the password, ... > encrypt the timestamp) still be susceptible to brute-force> using dictionary ...
    (Focus-Microsoft)
  • RE: Can Kerberos be cracked??
    ... If you were able to decrypt the timestamp ... As for your assumption about the hash being as good as the password, ... > encrypt the timestamp) still be susceptible to brute-force> using dictionary ... The server doesn't actually know what the user's>>password is, ...
    (Focus-Microsoft)
  • Re: Can Kerberos be cracked??
    ... > against the encrypted timestamp. ... > As for your assumption about the hash being as good as the password, ... >> encrypt the timestamp) still be susceptible to brute-force ... The server doesn't actually know what the user's ...
    (Focus-Microsoft)
  • Re: Problems with public key decryption with RSA
    ... with securing the "Private key" at the clients. ... Encrypt key / IV with public RSA key of server. ... Sign hash and sign data elements with HMAC-SHA1 using symmetric key. ...
    (microsoft.public.platformsdk.security)
  • Re: Problems with public key decryption with RSA
    ... with securing the "Private key" at the clients. ... Encrypt key / IV with public RSA key of server. ... Sign hash and sign data elements with HMAC-SHA1 using symmetric key. ...
    (microsoft.public.dotnet.security)
Loading