This is correct... Since I treat Redmond software as if it were
covered with smallpox these days, I didn't even think to mention
it. Their salt scheme is a problem, their LanMan stupidity is a
problem, and the fact that they did not create any patches to bring
Win9x up to NTLM v.2 is a very irresponsible problem. If you plan on
using Win2k you need to do two things, one Upgrade all clents and
servers to NTLM v.2 (as Patrick pointed out), the second has to do
with purchasing a weapon to harm the individuals who made that
decision, including yourself.

<NT_RANT>
I don't mean to rant on the evils of NT. We've seen that enough
here. But, I really cannot understand how any security conscious
person worth their salt would not denounce any solution based on
technology with such a flawed history. There has not been an encryption
scheme come out of the bowels of Redmond that has not had kindergarten
crypto mistakes. 
</NT_RANT>


Patrick Prue writes:
 > The main issue here lies within the backwards compatibility of LAN Manager
 > Support which breaks the passwords down into 7 character chunks that are all
 > non case sensitive.
 > 
 > You can increase the time that l0pht would take dramatically simply by
 > editing the registry to do only NTLM v 2 with no fall back to LAN manager.
 > This of course would eliminate 9x machines being able to login to the
 > network as well as any older Nt machines ( Pre Sp4 ) .
 > 
 > By enabling only NTLM then your 14 character password becomes exactly that,
 > a  case sensitive 14 character password which would take far longer to run
 > through. BUT.. given the current speeds of processors.
 >  ( Benchmarks given are 480 hours to run all possible combinations on a quad
 > xeon 400 ) but this time is probably drastically reduced say running it on 8
 > way Xeon 700s or higher.
 > 
 > And Microsoft actually does salt the passwords when they are encrypted it
 > just so happens its the exact same salt for every password : ) 
 > 
 > 
 > 
 > -----Original Message-----
 > From: "D. Clyde Williamson" <D Clyde Williamson
 > [mailto:[EMAIL PROTECTED]]
 > Sent: Friday, December 22, 2000 10:05 AM
 > To: Graham, Randy (RAW) 
 > Cc: 'Chris Williamson'; [EMAIL PROTECTED];
 > [EMAIL PROTECTED]
 > Subject: RE: NT password encryption & name service
 > 
 > 
 > 
 > No this is correct. The entire problem with NT's broken scheme hinges
 > on this. Longer passwords don't make safer passwords. Yech!
 > 
 > 
 > Graham, Randy \(RAW\)  writes:
 >  > -----BEGIN PGP SIGNED MESSAGE-----
 >  > Hash: SHA1
 >  > 
 >  > The reason you get more possible passwords than Chris is because you
 >  > assume an 8 character password is ((26 + 26 + 10 + 12)^7) * (26 + 26
 >  > + 10 + 12) passwords, when because of Microsoft splitting each
 >  > password into 7 character parts (which can be decrypted seperately)
 >  > an 8 character password has ((26 + 26 + 10 + 12)^7) + (26 + 26 + 10 +
 >  > 12) possibilities.  Notice that is a + in the middle there. 
 >  > Likewise, a 10 character password (as you gave as an example below)
 >  > is actually a 7 character password plus a 3 character password for
 >  > decryption purposes - I come up with 12,151,280,678,248, which is far
 >  > less then what you came up with.  Therefore there are only
 >  > (74^7)+(74^3) possibilities instead of 74^10.  I actually think Chris
 >  > calculated too high.
 >  > 
 >  > Unless I'm misunderstanding the l0pht documentation on this terribly,
 >  > what it says is every password can be broken in to two 7 character
 >  > chunks, each chunk independent of the other.  Therefore, going from 7
 >  > characters to 8 characters only adds 74 additional passwords to
 >  > decode (assuming the character set you mentioned below).  That is why
 >  > someone on this list (already deleted the message, and don't want to
 >  > search just to get a name) said he only used 7 character of 14
 >  > character passwords.  Certainly 8, 9, 10, 11, and probably even 12
 >  > character passwords don't gain you much beyond 7 characters.  And to
 >  > make it all worse, Microsoft doesn't even salt the passwords, so user
 >  > A and user B will have the same encoded password from the same
 >  > plaintext.
 >  > 
 >  > If I am horribly off here, I'm sure someone will let me know.
 >  > 
 >  > Randy Graham
 >  > 
 >  > 
 >  > - -----Original Message-----
 >  > From:     Chris Williamson [SMTP:[EMAIL PROTECTED]]
 >  > Sent:     Thursday, December 21, 2000 6:05 PM
 >  > To:       [EMAIL PROTECTED]
 >  > Cc:       [EMAIL PROTECTED]
 >  > Subject:  Re: NT password encryption & name service
 >  > 
 >  > Chris Hastings was incorrect in his calculation...
 >  > 
 >  > There are only two options in L0phtcrack with special characters, one
 >  > with
 >  > 12
 >  > Make that (26 lowercase + 26 uppercase + 10 numerals + 12 special
 >  > characters)^8 with a total of
 >  > 899 194 740 203 776 (twice as many as Chris calculated,
 >  > 457,163,239,653,376)
 >  > 
 >  > and the other with 32 with a total of
 >  > 6 095 689 385 410 816
 >  > 
 >  > If you use a combination of any special character and increase to 10
 >  > characters in length you should be fairly secure
 >  > 53 861 511 409 489 970 176
 >  > 
 >  > Or if you are paranoid like my buddy Greg who uses 13 mixed
 >  > characters
 >  > 44 736 509 592 539 817 388 662 784
 >  > I reckon if he changes this once a month he should be able to stay
 >  > ahead of
 >  > a L0phtcracker
 >  > 
 >  > Regards
 >  > Chris Williamson :)
 >  > 
 >  > - ----- Original Message -----
 >  > From: <[EMAIL PROTECTED]>
 >  > To: Bobby Brown <[EMAIL PROTECTED]>
 >  > Cc: <[EMAIL PROTECTED]>
 >  > Sent: Wednesday, December 20, 2000 7:52 PM
 >  > Subject: RE: NT password encryption & name service
 >  > 
 >  > 
 >  > >
 >  > > Using this password as an example (for length and character type),
 >  > > the number of possibilities
 >  > > would be (26 lowercase+26 uppercase+10 numerals+6 special
 >  > > characters)^8 (assuming that the
 >  > > period at the end of the sentence isn't part of the password). 
 >  > > This is a total of 457,163,239,653,376
 >  > > possibilities (compare this with DES encryption at 56-bit which we
 >  > > all 
 >  > know
 >  > > can be brute forced at
 >  > > 72,057,594,037,927,936 possibilities).  If you have the period at
 >  > > the end 2^54 < 68^9 < 2^55 possibilities.
 >  > > Better but still fewer possibilities than 56-bit encryption...
 >  > >
 >  > >
 >  > > Chris Hastings
 >  > > Manager, Network Security
 >  > > Network Computing Services
 >  > > Vanderbilt University Medical Center
 >  > > [EMAIL PROTECTED]
 >  > >
 >  > >
 >  > >
 >  > >                     Bobby Brown
 >  > >                     <bbrown@allensysgrou        To:
 >  > "'[EMAIL PROTECTED] '"
 >  > >                     p.com>                     
 >  > > <[EMAIL PROTECTED]> 
 >  > >                     Sent by:                    cc:
 >  > >                     firewalls-owner@List        Subject:     RE: NT
 >  > password encryption & name
 >  > >                     s.GNAC.NET                  service
 >  > >
 >  > >
 >  > >                     12/20/2000 11:14 AM
 >  > >
 >  > >
 >  > >
 >  > >
 >  > >  You must have had very few users or an extremely powerfull server
 >  > > to 
 >  > crack
 >  > > by brute force the passwords. The password you referenced has 4 of
 >  > > the recommended characters I wish every user used. Upper and lower
 >  > > case characters, special characters, and numbers. What cracking
 >  > > software did 
 >  > you
 >  > > use to do this ?
 >  > >
 >  > >
 >  > > Bobby Brown
 >  > >
 >  > > -----Original Message-----
 >  > > From: Carl Ma
 >  > > To: [EMAIL PROTECTED]
 >  > > Sent: 12/20/00 12:00 PM
 >  > > Subject: NT password encryption & name service
 >  > >
 >  > > Hello all,
 >  > >
 >  > > After running password cracking program on our W2000 PDC server,
 >  > > 98% passwords
 >  > > are cracked out, even some very complicate passwords like -
 >  > > X1#!h0a_. 
 >  > >
 >  > > Is it attribute to the W2000 encryption method? I would like to
 >  > > persuade my boss
 >  > > using LDAP as name service. Appreciate any information & idea! I
 >  > > will summarize.
 >  > >
 >  > > Thanks & Merry Christmas!
 >  > >
 >  > > carl
 >  > >
 >  > > -
 >  > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
 >  > > "unsubscribe firewalls" in the body of the message.]
 >  > > -
 >  > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
 >  > > "unsubscribe firewalls" in the body of the message.]
 >  > >
 >  > >
 >  > >
 >  > >
 >  > > -
 >  > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
 >  > > "unsubscribe firewalls" in the body of the message.]
 >  > 
 >  > - -
 >  > [To unsubscribe, send mail to [EMAIL PROTECTED] with
 >  > "unsubscribe firewalls" in the body of the message.]
 >  > 
 >  > 
 >  > -----BEGIN PGP SIGNATURE-----
 >  > Version: PGP Personal Privacy 6.5.3
 >  > 
 >  > iQA/AwUBOkNsVxmX7SWIy+ClEQL6RwCgh5c9yDgdLjh6UbIOtXPeTaN/AIkAoIro
 >  > lTx96QZ5L/G7P1bpCFVpmoO4
 >  > =2KhY
 >  > -----END PGP SIGNATURE-----
 >  > -
 >  > [To unsubscribe, send mail to [EMAIL PROTECTED] with
 >  > "unsubscribe firewalls" in the body of the message.]
 > 
 > -
 > [To unsubscribe, send mail to [EMAIL PROTECTED] with
 > "unsubscribe firewalls" in the body of the message.]

-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to