I'm no expert on the subject, but I do believe brute forcing something like hotmail is very different to say.. brute forcing a sam._ file. Mainly because the only way you can brute force something like hotmail is to create some kind of script to log in as a username and brute force the password? Which would be very bandwidth consuming, as well as hotmail probably blocking connections after a certain amount of bad password attempts.
Jo > 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? > > > > > > > > > > > > > > > > > > > > > > > >
