Letters-Only LM Hash Database

Peter Clark writes "Disk storage has increased tremendously in the past 5 years and the blatant insecurities in the antiquated LM hashing technique have not gone away; though functionality has been added to disable LM hashes, this is not set by default. With some help from Elcomsoft, simple flat files have been created that hold every combination of LM hash for letters only passwords. Jesko has coded a server application which allows you to access this database. Simply telnet to: beginningtoseethelight.no-ip.org on port 2501 and paste in a LM hash. So how does this differ from Rainbow tables? Well this will return a password 100% of the time, using minimal processor power, in approximately less than 0.2 seconds."

Comments

Someone explain?

[mistersooreams]

Anyone feel that a article summary with this much technical detail should have some links or explanation of what it's actually talking about? And since I'm one of the ignorati who doesn't understand, could some please explain to me?

of course...

[Qwerpafw]

The files increase exponentially in size for passwords which include numeric characters. While the security risk exists, good password design obviously minimizes it. People aren't going to be lugging around terabyte-sized password database files.

Re:of course...

[Jeffrey Baker]

Why not? A terabyte fits in a briefcase these days, and a remote attacker is not constrained by space. A petabyte of storage is barely one rack's worth and not very expensive, either.

Non sequitur?

[Nighttime]

Disk storage has increased tremendously in the past 5 years and the blatant insecurities in the antiquated LM hashing technique have not gone away;

Maybe I'm being a bit thick here but how does the first part of that sentence relate to the other?

Re:modeling unknown passwords

[Dun Malg]

There's gotta be a better way to model what a user's password can be than just all combinations of only letters, or a list of common passwords plus substitutions. I think these are the only ones I've seen. But this doesn't really reflect that "fiqojeio" is a much less likely password than say "foo7bar+".

I see this as mostly just a harbinger of Things To Come. At what point will it become a trivial matter to generate a database of all possible hashes of all possible passwords (incl. all symbols and numbers), and what will we do when that point is reached? Hide the hash file? Isn't that why we moved to hashes in the first place, because hiding the password file just didn't work?

Hashes

[CastrTroy]

I had a thought last month, when there was news of duplicates being found in the MD5 hash. For security purposes, couldn't we just use the MD5 hash along with the SHA1 hash. Would there be any string of data which held the same hash for both MD5 and SHA1? This could help increase the power of digital signatures. Anyway, this database of hashes and passwords only works for letter-only passwords, which are assumed to be quite easy to brute force anyway.

you need only a bit more than half of it

[awolk]

Assuming you have to store 7 bytes for the hash and 7 bytes for the plain text, that's 14 bytes per record and 68^7 records, or 86PiB. At today's density that's a bit over 200 hard drives, not "a single hard drive."

As far as I'ver understood it, every possible 7byte hash exists somewhere.
Therefore you could sort the plaintext which belongs to the hash after the hash's number.
Don't know if I'm unclear, but here is a example using single-digit-decimal numbers up to 4 (two digit binary):

[hash] / [password]
1 / 2
4 / 3
2 / 1
3 / 4

this, to save half of the space could be written as:
2
1
4
3

whereas the row number/place in the file is the hash belonging to it
.
So you would just have to jump to the row with the same number of the hash you are looking for.
Something would be needed to separate the passwords from eachother though, because the differ in length.

Therfore it would be slightly larger than the half size ..

Re:Holy Ratshit, Batman!

[Anonymous Coward]

Please, please tell me you are joking.

Nope, that's what they did.

And more fun facts with LM hashes, your password isn't as secure either in LM. As was said before the password upper cases every letter. It only supports up to 15 characters. It breaks up passwords longer than 7 characters into two hashes which are much easier to break.

So pretty much any password is not going to be good enough using LM =/

Re:modeling unknown passwords

[freqres]

Just use a salt in computing the password hash. Makes the space requirements for precomputing the hashes go up many many orders of magnitude.

How to NOT store LM Hash

[siliconjunkie]

I've read a lot of this thread and haven't noticed anyone commenting on the fact that the storage of LM hashes in Windows NT/2000/XP (yes, XP has LM hashes stored by default) can be TURNED OFF (and REALLY should be)

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentContro lSet\Contro l\Lsa
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type NoLMHash, and then press ENTER.
5. On the Edit menu, click Modify.
6. Type 1, and then click OK.
7. Restart your computer, and then change your password.

The above steps are one of the first things you should any Windows NT kernel machine that you don't want people getting into, and as you can see by this article, getting into a machine with LM hash intact is a trivial exercise at best.

For NT and Win2K there are full details here.