We all know about how the password should have a numbers, upper case,
lower case and puncuation marks for more security ( ie to prevent brute
forcing )
But how does one make passwords for things like hotmail
Where the choice is just numbers, uppercase and lower case without
puncuation marks plus the password length is limited to 16 char ( or
less )
Any one got good suggestions for this one
Ps hotmail is just taken as a example!
Aditya
> -----Original Message-----
> From: John Forristel [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 04, 2002 9:42 AM
> To: Richard Conlan; [EMAIL PROTECTED]
> Cc: Chris Berry; [EMAIL PROTECTED]
> Subject: Re: Password Strength II
>
>
> Here is an OLD article on LANMAN hash's (from 1997). Mudge
> wrote it on l0pht Crack 1.5 and how weak MS made the
> passwords and why:
>
> If the "charts" get screwed up, here is the link:
> http://www.insecure.org/sploits/l0phtcrack.lanman.problems.html
>
> Now, let's rip apart why it is so trivial to go through the
> LM hash on the network. And then talk about why the NT hash
> doesn't matter.
>
> -------------------------- -----------------------------
> | 16byte LM hash | | 16byte NT hash (md4) |
> -------------------------- -----------------------------
>
> We already know that you only have to go through 7 characters
> to retrieve passwords (up to 14 chars in length) in the LM
> hash, and that since there is no salting being done,
> constants show up all over the place giving away too much
> information and speeding up attacks tremendously.
>
> -------------------------------------------------
> | 1st 8bytes of LMhash | second 8bytes of LMhash |
> -------------------------------------------------
>
> 1st 8 bytes are derived from the first seven characters of
> the password and the second 8 bytes are derived from the 8th
> through 14th characters of the password. If the password is
> less than 7 characters then the second half will always be:
> 0xAAD3B435B51404EE.
>
> Let's assume for this example that the users password has a
> LM hash of 0xC23413A8A1E7665fAAD3B435B51404EE (which I'll
> save everyone the nanosecond it would have taken for them to
> plug this into L0phtcrack and have it tell them the password
> is "WELCOME").
>
> Here's what happens to this hash on the network:
>
> -------- --------
> | A | <______________| B |
> | | | |
> -------- --------
>
> B sends an 8 byte challenge to A. (assume 0x0001020304050607)
>
> Machine A takes the hash of 0xC23413A8A1E7665fAAD3B435B51404EE
> and adds 5 nulls to it, thus becoming
> 0xC23413A8A1E7665fAAD3B435B51404EE0000000000.
>
> The string 0xC23413A8A1E7665fAAD3B435B51404EE0000000000 is
> broken into three groups of 7:
>
> C23413A8A1E766 5fAAD3B435B514 04EE0000000000
>
> The 7 byte strings are str_to_key'd (if you will) into 8 byte
> odd parity des keys.
>
> Now we have :
>
> | 8byteDeskey1 | | 8byteDeskey2 | | 8 byteDeskey3 |
>
> 8byteDeskey1 is used to encrypt the challenge
> 0x0001020304050607. Let's assume the result is 0xAAAAAAAAAAAAAAAA.
>
> 8byteDeskey2 is used to encrypt the challenge
> 0x0001020304050607. Let's assume the result is 0xBBBBBBBBBBBBBBBB.
>
> 8byteDeskey3 is used to encrypt the challenge
> 0x0001020304050607. Let's assume the result is 0xCCCCCCCCCCCCCCCC.
>
> The three 8byte values are concatenated (!dumb!), and the 24
> byte response of 0xAAAAAAAABBBBBBBBCCCCCCCC is returned to
> the server. The server does the same thing to the hash on
> it's end and compares the result to the 24 byte response. If
> they match, it was the correct original hash.
>
> Why this is boneheaded:
> ----------------------
>
> 7 char or less passwords.
>
> -------------------- -------------------- --------------------
> | C23413A8A1E766 || 5fAAD3B435B514 || 04EE0000000000 |
> -------------------- -------------------- --------------------
>
> The first thing we check is to see if the users password is
> less than 8 characters in length. We do this by taking the 7
> byte value of 0x04EE0000000000, turning it into an 8 byte odd
> parity DES key, and encrypting it against the 8 byte
> challenge of 0x0001020304050607. If we get the result of
> 0xCCCCCCCCCCCCCCCC then we are pretty sure it's < 8 chars in length.
>
> In order to be sure we can run through 0x??AAD3B435B514 (ie
> 256 possible
> combinations) to see that 5f shows us the result is
> 0xBBBBBBBBBBBBBBBB, proving that the password is less than 7
> characters and also giving us the last byte of the first half
> of the LM hash.
>
> >>From this point, even assuming we're just joyriding and not worried
> >>about
> optimizing the way this is done (believe me, there are much
> more effective ways to do this that reduce the amount of time
> needed even further... this whole this is just showing that
> even a simplistic attack works against this implementation),
> it's no different than how a tool like L0phtcrack attacks the
> hashes in the registry.
>
> 8 char or greater passwords.
>
> -------------------- -------------------- --------------------
> | C23413A8A1E766 || AC435F2DD90417 || CCD60000000000 |
> -------------------- -------------------- --------------------
>
> The first thing to check is whether the password is less than
> 8 characters in length. Deriving the 8 byte odd parity des
> key from 0x04EE0000000000 and encrypting against
> 0x0001020304050607 does not, in this case, give us
> 0xCCCCCCCCCCCCCCCC, so we know that the password is 8
> characters or greater.
>
> It takes us, in a worst case scenario, 65535 checks to figure
> out that the 2bytes that are used in the last third are
> 0xCCD6. Even approaching this in a completely brain-dead
> fashion (hey, turn-about is fair play), you can go through
> your 7 digit combinations of characters for the first third
> the same way you would the LM hash from the registry. This
> will yield not only the first third of the response, but also
> the first byte of the second third. Keep in mind that you
> already have the last two bytes that made up the third third.
>
> You could approach the middle third in the same fashion.
>
> (note: this whole method that MS is doing screams for a
> precompute table lookup attack - which given the small enough
> potential values is not impossible by any means)
>
> Thus, the challenge response is completely brute-forcable for
> the LM-hash.
>
> MS made the "oversight" of still sending the LM-hash response
> along with the NT response even when SP3 was installed. Thus
> it was a moot point as to how tough or well done the NT hash
> might or might not be.
>
> Since installing the LM-fix precludes continued use of
> windows 95 machines in regards to talking to NT machines, it
> is still a moot point as to how tough or well done the NT
> hash might or might not be.
>
> The LM hash is incredibly weak and your more secure NT hash
> is brought down to the lowest common denominator.
>
> Thus, the challenge response is completely brute-forcable for
> the LM-hash.
>
> MS made the "oversight" of still sending the LM-hash response
> along with the NT response even when SP3 was installed. Thus
> it was a moot point as to how tough or well done the NT hash
> might or might not be.
>
> Since installing the LM-fix precludes continued use of
> windows 95 machines in regards to talking to NT machines, it
> is still a moot point as to how tough or well done the NT
> hash might or might not be.
>
> The LM hash is incredibly weak and your more secure NT hash
> is brought down to the lowest common denominator.
>
>
> ----- Original Message -----
> From: "Richard Conlan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: "Chris Berry" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Tuesday, July 02, 2002 8:23 AM
> Subject: Re: Password Strength II
>
>
> > Where did you get that NT4 only encrypts the first eight
> characters?
> > It was my understanding that it used the first fourteen to come up
> > with the LANMAN hash, but that regardless it stored the entire
> > password in some "secure" format. Is this untrue, or are
> you mistaken
> > in your statement?
> >
> > On Sun, 30 Jun 2002 [EMAIL PROTECTED] wrote:
> >
> > >
> > >
> > > I would say 2 things, to be confirmed by some expert :
> > >
> > > 1) In systems like NT4, only the 8 first digits are
> encrypted, the
> > > rest
> of
> > > the password is stored in the clear. In your case
> "VX.97tf" is then
> > > much secured than "theusgot" (68^7 compared to (8digits words
> > > number) +
> (7digits
> > > word number + 68) + (6digits word number * 2 digits word
> number) +
> > > (6 digits word number * 68^2)...)
> > >
> > > (note that the number of solutions using brute force is easy to
> calculate,
> > > but not the one in dictionnary-based attacks, especially when the
> > > number
> of
> > > digits is knew, and especially if some semantic rules are used)
> > >
> > > More simply one can suppose that "theusgot" can be guessed more
> > > easily
> by a
> > > cracker soft than "VX.97tf", don't you think so ?
> > >
> > > 2) If the number of encrypted digits is more than 8, obviously the
> strength
> > > of your password has something ("something", not
> "everything" !) to
> > > see with its length. So in your case, you should compare the
> > > strength of " theusgotbeatbygermany" to "kjdASFD234$&%$#sfsCS>".
> > >
> > >
> > > To summarize:
> > > there are rules that you forgot in how to measure the strength of
> > > the password (for example the length of it, how many
> characters are
> encrypted,
> > > and others I don't know),
> > >
> > > and
> > >
> > > when you compare 2 things, take the same rules to compare them (I
> > > can guarantee you that the password
> "theusgotbeatbygermany" is more
> > > secure
> than
> > > the randomly generated password ";". I just forgot the length has
> > > its
> > > importance)
> > >
> > > my 2 cents, not explaining the whole thing, but bringing some
> > > ideas...
> > >
> > > seb
> > >
> > >
> > >
> > >
> > >
> > > Chris Berry
> > > <compjma@hotmail. To:
> [EMAIL PROTECTED]
> > > com> cc:
> > > Subject: Password
> Strength II
> > > 2002/06/28 08:48
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I've gotten quite a few responses saying no because the
> passwords I
> asked
> > > about previously (theusgotbeatbygermany vs. VX.97tf) had
> dictionary
> words
> > > in it, which is what I've always told my users in the
> past, however
> > > I
> was
> > > doing some math and it makes it look different, maybe
> someone here
> > > can point out my error.
> > >
> > > In a brute force attack the longer password will always
> be better,
> > > we're all agreed on that, however hackers are smarter
> than that and
> > > will try dictionary and hybrid attacks first. So this is what I
> > > think the odds
> are
> > > approximately:
> > >
> > > VX.97tf has to be brute forced so 68^7=6x10^12 certainly a big
> > > number
> and
> > > good to go in my book.
> > >
> > > theusgotbeatbygermany doesn't have to be brute forced, and is
> susceptible
> > > to a dictionary attack so instead of letters the
> possiblity is based
> > > on individual words which is 6, the LC4 program standard
> dictionary
> > > has
> 29000
> > > entries (approximately) so we're looking at
> 29000^6=5x10^26 A BIGGER
> > > NUMBER! (not to mention making it impossible to store in
> a LM hash)
> > >
> > > Am I missing something?
> > >
> > >
> > >
> > >
> > >
>
