=====================================Kaos=Keraunos=Kybernetos============== .+.^.+.| Ray Arachelian | "If you're gonna die, die with your|./|\. ..\|/..|sunder@sundernet.com|boots on; If you're gonna try, just |/\|/\ <--*-->| ------------------ |stick around; Gonna cry? Just move along|\/|\/ ../|\..| "A toast to Odin, |you're gonna die, you're gonna die!" |.\|/. .+.v.+.|God of screwdrivers"| --Iron Maiden "Die With Your Boots on"|..... ======================== http://www.sundernet.com ========================= For with those which eternal lie, with strange eons even death may die. ---------- Forwarded message ---------- Date: Thu, 10 Apr 1997 18:10:04 +0000 From: Alan C. Ramsbottom <acr@als.co.uk> To: Jos Visser <josv@osp.nl> Cc: ntsecurity@iss.net Subject: Re: [NTSEC] GOOD GRIEF! re:Hack' punches hole in Microsoft NT s

I am currently reviewing the write-up to include the newest relevant information.I had considered the possibility that you could brute-force attack the password space. However, the possible number of passwords is quite bi. Let us assume that the average password contains about 40 bits of information, the entie plausible passowrd space then is 2^40 = 1099511627776 possible passwords. Suppose you could hash and store 1,000,000 passwords each secondthe brute-force approach takes more then 12 days to calculate and requires about 16 GB diskspace to store the results (uncompressed).

Could you please point me the errors in my calculations so I can fix the article asap?

Certainly.. Theoretically, for a "complete" brute-force attack on the DES hashes we need to consider a 56 bit ( 7 chars x 8 bits) password space. This space is the maximum we have to worry about because of the 14 char password to two independent 7 char DES keys split. The timing overheads of checking both the 8 char hashes during a brute-force attack are relatively trivial. Now the crunch. Theory is fine, but in the real world there are constraints on the password space - in reality it gets much smaller e.g. 1) chars below 0x20 can't be entered in the password dialogue box 2) alphas are uppercased prior to being used as DES keys so you can also ignore 0x61 to 0x7A. Correcting the case of any alphas after finding a LanMan password is a quick and relatively trivial task using MD4. That much is guaranteed even if you (reasonably in 99.99% of cases) start throwing away characters that are difficult to quickly enter on a keyboard e.g. anything that needs an ALT-0-nnn sequence to enter (more or less everything above 0x80 subject to country). Finally 3-4Gb disks are now relatively inexpensive so the amount of diskspace required for a precomputed attack is not much of an obstacle. It has been also been suggested that if you are short of diskspace you could always keep sequentially sorted sections of the precomputed file on a backup tape. Then, as you mention above there is compression. My main point is that you don't need an exceptionally fast machine or impossible amount of disk space. If I can write code to do this then you can guarantee that other people have, and that theirs is both cleverer and runs faster ;-) "Greater password complexity" is a good idea for many reasons but not much help in this specific case. The LanMan hashes are simply far too easy to attack and you should concentrate your defences in preventing access to them. Finally, we need to put this in proper perspective - this attack and the associated IE 3.0 SMB and NTLM problems can EASILY BE AVOIDED with a few simple network administration policies. --Alan-- acr@als.co.uk PS. Haven't seen my original message turn up on NTSecurity yet so I don't suppose this will.