Let’s say I’m using a 56-bit NTLM password; sending and storage of the LM hash is disabled. Does anyone know how much CPU time it’d take to break a password of that length? If l0phtcrack is the fastest thing out there, I’m thinking it’s just moore’s law * search speed * search space.
Not that I’m really concerned with having my precious domain controller broken; I’m just curious. I swear I saw an RFC on password strength/cost to break somewhere, but I can’t find it.
If you have physical access to the machine you’re god, that’s accepted.
I haven’t heard of any NTLM backdoors, it’s supposed to be a clean 1-way hash. Given that, I’d agree with your equation.
Covering the 8 char [A-Z,a-z,0-9] namespace takes around 300 days on a 3Ghz p4 desktop. Going by moore’s law, it would take a month to crack in 2009 and a day to crack in 2012.
Of course if cracking passwords is your game you probably would blow a couple of grand and get some dual xeons to start off, upgrading as appropriate every cycle. It won’t be ms-word-level weak encryption for years, but I wouldn’t put any faith in a 56-bit hash right now.
Followup: are passwords going to become totally worthless in ten years? Who the hell will remember a 30 character password?
Edit: just for kicks, I tried to generate a 20 character mostly random password and remember it. Maybe if I did nothing but try to remember it for 2 weeks; jesus.
Umm, no. You’re confusing password length with keylength.
57 bit encryption is twice as hard to break as 56. SSL is 128bit. 1024bit should be enough to last through our grandchildrens’ lifetimes, assuming that nobody comes up with a sneakers-esque backdoor to factor prime numbers without doing the grunt work.
My point was that you need a 20 character mostly-random password to get 128-bit. If you think chosen passwords are bad now, god only knows what they’ll look like in a few years.
There is no relationship between password length and encryption strength. You can use 128-bit encryption on a password that’s only 2 characters long and it’s still 128-bit encryption. Likewise, a 2 character password with 128 bit encryption is still going to take longer to crack than the exact same password with 48-bit encryption.
There is no relationship between password length and encryption strength. You can use 128-bit encryption on a password that’s only 2 characters long and it’s still 128-bit encryption. Likewise, a 2 character password with 128 bit encryption is still going to take longer to crack than the exact same password with 48-bit encryption.[/quote]
Erm, maybe I wasn’t clear - if your password is 20 characters long and composed of case sensitive alphanumeric + punctuation, the “search space” for finding it with a brute force attack is about 128 bits wide.
And do you have any more details on that crack cd? I think it’s an exploit of storing pre-NTLM v2 hashes.
It’s far more computationally intensive to bruteforce a 128-bit hash than a 56-bit hash. It would take twice as long to cover the A-Z,a-z,0-9,1:8 namespace running against a 57-bit hash versus a 56-bit hash, for example.
Once your password passes a certain quality threshold you start to hit greatly diminishing returns. You can probably remember “[email protected]” without much difficulty, not so with more obfuscated passswords. That’s why encryption nuts use passphrases instead. Not necessary, but they seem to like it.
I do faintly remember one backdoor exploit admin password crack, but that’s been patched for years. Probably before win2k. None of the current bootcds will crack the admin password for you. They will allow you to change it to whatever you want, however.
I did some reading, and that floppy is probably the “SAM overwrite” exploit. On a non-domain controller, you can just overwrite the password area of the registry with a new password.
pro tip: regedit doesn’t let you see the SAM, so you can’t wipe the admin password that way. UNLESS THE REGEDIT PROCESS RUNS AS ROOT!
try this in a console window:
at 11:30 /i regedit
automatically runs regedit at 11:30 as root, and the /i tag causes the window to be “interactive”, i.e. show up on your logged in users’s screen.
you can now browse the SAM hive nder HKEY_LOCAL_MACHINE.
Use HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names\Administrator to find your Administrator’s account name representation in binary. Mine’s listed as 0x1f4.
so i open HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\000001F4 and see two keys, F and V. i’m pretty sure one of them is the root password and just needs to be deleted, but i forget which. i’m sure you can work it out from here.
Doesn’t a domain controller use a local sam account for the local admin? Overwriting is just as good as guessing as far as access to data stored on the machine.
