Unfortunately cases like that, you have only two choices: 1) Don't use such services for anything sensitive
and/or 2) Change the passwords for those services much more frequently than you do your other passwords, something on the order of 15 days or less | -----Original Message----- | From: Aditya Lalit Deshmukh [mailto:[EMAIL PROTECTED]] | Sent: Friday, July 05, 2002 22:53 | To: 'John Forristel'; 'Richard Conlan'; [EMAIL PROTECTED] | Cc: 'Chris Berry'; [EMAIL PROTECTED] | Subject: Password Strength III (?) | | | 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? | > > > | > > > | > > > | > > > | > > > | > | |
