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

less than 0.2 seconds

[Sediyama]

I think someone is underestimating the /. effect.

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?

Re:Someone explain?

[Jaruzel]

As I understand it LM Hashes can't be reversed. So what someone has done here is pre-hashed an entire dictionary, and created a word=hash lookup system.

You telnet to it, feed it the hash, and it replies with the word.

LM hashes are how a lot of passwords are 'encrypted'

Excuse the fuzzy description... Crypto is not my strong point.

Re:Someone explain?

[kapella]

You're not cleared for this. Nothing to see here. Move along.

Re:Someone explain?

[Anonymous Coward]

http://en.wikipedia.org/wiki/Lm_hash

Re:Someone explain?

[terraformer]

They are talking about the hashing algorithm MS uses on Windoze machines and networking. LM stands for LanManager which is what the networking component in windows has been called since as far back as I can remember. What I wish people would do is send up some examples to test out. Those without regular access to windows would benefit greatly. Also, I wish I could shed some more light on the letters only thing, but I am confused as to whether that is for the hashed passwd or the hash itself. I suspect it may be the passwd itself but I am not sure since it is not clear.

Re:Someone explain?

[Dun Malg]

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?

In simple terms, a hash is a sort of "one-way" function. Passwords are often saved as hashes. THe password is fed in one end, and the hash comes out the other. The hash is saved in a file. When one logs in and types in one's password, the system feeds what you typed in through the hash function and checks if the result matches the hash of your password. Since there is no way to reverse the hash process, it's been considered fairly safe to leave these hashes moderately unprotected. This database is, presumably, a sorted collection of the possible hashes from all letters-only passwords up to a certain length. The hash can't be reversed to get the password it came from, but a huge database of all possible hashes and their originating passwords certainly makes that irrelevant.

Re:Someone explain?

[Doctor Memory]

I suspect it may be the passwd itself but I am not sure since it is not clear.

Of course it's not clear, it's been hashed -- haven't you been following along?

Re:Someone explain?

[Blastrogath]

LM hashes are Lan Master hashes, an old microsoft standard.

They're not used much anymore because they're ludicrously insecure yet windows still makes a LM hash of all passwords by default. You can easly get someone's (administrator) password from these hashes, and the hashes aren't hard to get from a computer.

They're not used and can give others your password, and now there's a site that'll give you any letters only password from it's hash in seconds.

Re:Someone explain?

[destiny_uk]

Well if you retreive the password hash from an NT box, you can lookup the password with this database. However there are ways of securing this now.

Re:Someone explain?

[tshak]

They are talking about the hashing algorithm MS uses on Windoze machines and networking

The hashing algorithm used since NT4SP3 and Win2K is NTLMv2, whereas "lanman" is NTLMv1. NTLMv2 is significantly more secure, however, for backward compatibility with older Windows 9x machines some companies still use NTLMv1.

Re:Someone explain?

[Anonymous Coward]

I think the site you were looking for was this one:

LM Hash

Re:Someone explain?

[gclef]

This database is, presumably, a sorted collection of the possible hashes from all letters-only passwords up to a certain length

Actually, last time I checked, most versions of windows that used LanManager hashes split the password string into a new hash every 7 characters (yes, that is incredibly stupid). In other words, if your password was 8 characters long, there would be two hashes for your password: one that covered the first 7 characters, and one that covered the last 1 character.

So, I would assume the folks here have done every letter combination for up to 7 character long passwords, since that's all they'd need to do.

Re:Someone explain?

[kentmartin]

That link is most helpful - thanks.

Funny this is, when I glanced at the title of this page, I read "Letters of mass destruction". Very droll.

Re:Someone explain?

[Anonymous Coward]

I like your material and would like to hire you for my comedy act.

Re:Someone explain?

[terraformer]

I reread it and now it makes more sense.

Re:Someone explain?

[gweihir]

As I understand it LM Hashes can't be reversed.

That is untrue. Any hash can be reversed in the sense that you can generate an input that will result in a specific output. However the input may not be the only one generating that output and it may be computationally infeasible to do this for sufficiently random original inputs to the hash. The property of a (theoretical) perfectly secure hash is that you have to try possible inputs and hash them until you are lucky.

In other cases you might actually be able to reverse the algorithm itself and do without trying a lot of inputs. A hash were this is possible with significantly less effort is usually called "broken".

So what someone has done here is pre-hashed an entire dictionary, and created a word=hash lookup system.

Yes, that is called a "Dictionary Attack", and the dictionary is a function reversing the hash and given in the form of a table. Quite an old technique. But since LM hashes are not very secure, the possibility to do this is not surprising to anybody in the field.

Re:Someone explain?

[afidel]

however, for backward compatibility with older Windows 9x machines some companies still use NTLMv1.

Actually by default all passwords shorter than 14 characters are stored as BOTH LMv2 AND LMv1 hashes in the registry and both are valid for authentication if they are present. This is true for both Windows Server 2000 and Server 2003. You CAN disable the storage of LMv1 hashes but that does not remove any existing hashes from the SAM, you would also need to force LMv2 authentication and even then someone who could steal the SAM file could get the plaintext.

Re:Someone explain?

[kalidasa]

So, I would assume the folks here have done every letter combination for up to 7 character long passwords, since that's all they'd need to do.

Yep. The 124 Billion Names of Bill Gates.

Re:Someone explain?

[Anonymous Coward]

Curious where they are in the registry - it'd be interesting to see if LMv1 hashes are stored on the Windows-user's computers around here.

Re:Someone explain?

[afidel]

C:\WINDOWS\system32\config\SAM for XP and
C:\WINNT\system32\config\SAM for Windows 2000
There are tools out there like PWDUMP from SAMBA that can extract the hash from a SAM file.

Re:Someone explain?

[hazem]

Right on! Isn't there are "rule" somewhere about using the full form of an acronym before using the acronym?

A google for LM comes up with all kinds of things. Logistics Management, Land Mines.

Re:Someone explain?

[Ytsejam-03]

You CAN disable the storage of LMv1 hashes but that does not remove any existing hashes from the SAM, you would also need to force LMv2 authentication and even then someone who could steal the SAM file could get the plaintext.

I think in most cases simply turning off LM authentication altogether is sufficient. Sure, if someone could steal the SAM file, then they would get the existing hashes. However, if an attacker can get this kind of access to your system, then you have bigger problems. With this kind of access they could, for instance, install a keyboard logger to retrieve the passwords. If the passwords are that important to an attacker, then the attacker would likely just take his time cracking the NT hashes offline, should the LM hashes not be available.

IMHO the real risk here is someone sniffing the hashes off of the network.

Re:Someone explain?

[juan large moose]

I've written up the whole thing:

http://ubiqx.org/cifs/SMB.html#SMB.8.3

There are two things people always forget about LM Hashes:

1. They are not exposed on the wire.
2. They are password equivalent.

The LM logon protocol is challenge/response. The server sends a random 8-byte string (the challenge) and both client and server encrypt it. The client sends back the result (the response) and the server checks to see if the responses match. If so, you're in.

Note that the hash is not sent over the wire.

That's important, because (large databases and rainbow tables aside) you don't need the original password. The hash is computed with no salt, so it is completely password-equivalent. Someone with access to the above documentation and the LM or NTLM hash has all they need in order to fake a login.

Chris -)-----

Re:Someone explain?

[Foolhardy]

To stop this compatibility behavior, see the MS knowledge base article Q299656.

Basically, you want the security policy "Network security: Do not store LAN Manager hash value on next password change." in Group Policy->Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options.
Or you can set the registry value the policy sets directly: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa\NoLMHash.
Note that on 2000 and earlier, this prevents only the creation of new LM hashes; it does not delete old ones. The registry key on XP and 2003 clears all LM hashes.

This will also break connections to 9x machines unless they have the Active Directory Client update installed.

Re:Someone explain?

[Foolhardy]

Er, this page says that there is only one type of LM hash and two versions of NTLM. LM is supported for DOS, the original Lan Manager, and 9x. NTLM_V1 is supported on all versions of NT and NTLM_V2 is on NT4 SP3 and 9x with the Active Directory client update.

Re:Someone explain?

[biglig2]

They are used a lot more than you'd think, because if you still have Win9x boxes on your network (and lots do - I discontinued my last Win95 box last month) then you have to use LM hashes.

Re:Someone explain?

[juan large moose]

Excluding Kerberos authentication (which I should know more about, but don't) there are *two* hash types: LM and NTLM.

The LM Hash is used when performing LM challenge/response.

The NTLM Hash is used when performing NTLM, LMv2, and NTLMv2 challenge/response. Note that LMv2 is simply a degenerate case of NTLMv2.

I've written a book with a whole whoppin' big section on LM and NTLM auth: http://ubiqx.org/cifs/SMB.html#SMB.8.

Scroll down for information on specific auth protocols.

Chris -)-----

Re:Someone explain?

[themightythor]

So what someone has done here is pre-hashed an entire dictionary

Kind of. If I understand it correctly, for every LM hash someone has computed an input such that the hash of that input is the hash in question. This is different from what you're proposing in that with a dictionay attack, not every hash is guaranteed to be covered. In this case, someone has "computed" the reverse hash. That is to say that given an arbitrary hash value as input, you can get a value that hashes to that back as output.

Re:Someone explain?

[UnrefinedLayman]

The difference between getting a copy of the SAM database and installing a keystroke logger is huge. Namely, I can copy your SAM database without changing a single thing on your system. Installing a keystroke logger would require a service to be sure the password's picked up, and would alter your system.

While you're right that they have bigger problems if someone has that kind of access to their systems, simply saying "Hey, you're fucked if someone's that close to your box" is not very helpful as there are varying levels of being fucked, and sometimes the worst kind of fucking is when you don't even know someone's fucked you.

Re:Someone explain?

[DunbarTheInept]

It is not definitionally required that a hash must be one-way. It typically is because it is almost totally useless for it not to be, but techically any transformation of one string to another could be a hash, even if it is reversable. Heck, running "gzip" on a clear string and storing the resulting compressed string (which I realize would not be compressed smaller unless the input string was rather long) would fit the definition of a hash, and yet still be reversable.

The reason hashes typically are one-way is that they aren't all that algorithmicly useful unless they contain many-to-one mappings.

Re:Someone explain?

[Rosonowski]

That rule only applies when your audience is unlikely to know the meaning of the acronym in that context. Being that this is slashdot, a technically oriented site, it is more likely that your audience would know the meaning of the acronym in this context than not, thus, the rule does not apply.

Re:Someone explain?

[Foolhardy]

Ok. The page I liked to was about protocols, not hashes. I didn't know there was a LMv2, but apparently there is. Do 9x machines with the Active Directory client pack use LMv2? Microsoft says they use NTLMv2, but some things like case-insensitive passwords make me wonder.
Er, from your page it says

Under NTLMv2, however, the older NTLM (v1) Hash is used instead of the password to generate the new hash. A server or Domain Controller being upgraded to use NTLMv2 may already have the older NTLM hash values in its authentication database.

which implies that there are two types of NTLM hashes: v1 and v2. The v2 hash is the v1 hash plus the user name and "logon destination" (domain?), rehashed.

Anyways, your book is VERY informative; a veritable reference manual. I've bookmarked it.

Rabbit-pellet mode! :)
I've seen that; nice to have a name for it.

Re:Someone explain?

[Foolhardy]

If you are worried about that, besides disabling LM hashes, you can encrypt the entire SAM database with a password or random key on a floppy disk with syskey on NT4 and later. The key will be required at startup before you can logon.

Re:Someone explain?

[Ytsejam-03]

The difference between getting a copy of the SAM database and installing a keystroke logger is huge. Namely, I can copy your SAM database without changing a single thing on your system.

Agreed, perhaps that was a bad example. The point I was trying to make was that if you can get a copy of the SAM, does it really matter if the LM hashes are there or not? Either way an attacker is likely to do an offline attack on the SAM to find passwords for use on other systems. Does it really make that big of a difference if the attacker has to spend more time cracking the MD4 hashes because the LM hashes are not there?

In the ten or so years that I've worked in this industry, I've yet to work anywhere that requires password changes more frequently than ninety days. That should be plenty of time to crack an MD4 hash...

Re:Someone explain?

[michaelredux]

If I understand it correctly, for every LM hash someone has computed an input...

This is not correct. The hash of every possible combination of (7) letters has been calculated and stored in a large database. If you are searching for a password that has numbers or other characters in it, that hash will not be included in the database. There are also a very large number of "pseudo-hashes" which fall within the range of "hash-like" numbers, but do not result from any possible input.

So, to say that an "input" has been computed for every possible hash value is incorrect.

Re:Someone explain?

[juan large moose]

Thanks for the compliment. :)

Sorry for the confusion over the hashes. Let me explain...

Yes, there's such a thing as an NTLMv2 Hash. It is calculated using the NTLMv1 Hash, the username, and the login destination which may be a domain name or server name. That last input can (from the client's perspective) change with each login, so there's no real benefit (on the client side) of storing the NTLMv2 Hash.

It may be that Domain Controllers do store this value, but my guess is that they store only the NTLMv1 Hash and recalculate the NTLMv2 hash on the fly. The client is pretty much required to calculate the whole thing.

That's probably more detail that folks really want... :)

Chris -)-----
PS. The book is a reference manual... of sorts. The print version is 1.5 inches thick, and it includes the SNIA CIFS Technical Reference.
PPS. Rabbit pellet mode... One of the Ethereal folks thinks he's got this nailed. Seems there's a layering violation in Microsoft's stack. If the lower TCP layers sense changes in latency they send a message up the stack and the CIFS layer tries to compensate.

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.

Re:of course...

[EddieBurkett]

People aren't going to be lugging around terabyte-sized password database files.

Not yet they aren't, but it's not unreasonable to expect that someday they will. Then again, one would hope by that point sufficient encryption would exist such that anything vulnerable would have been replaced. It's not like people continue to run unpatched legacy systems nowadays. . .

Re:of course...

[GTRacer]

People aren't going to be lugging around terabyte-sized password database files.

I thought that was the whole point of this exercise - that a centrally-available hash master was viable.

And just out of curiosity, wouldn't the master file be really compressible?

GTRacer
- My PW's have always included numbers and often punctuation just for this reason

Re:of course...

[cduffy]

And just out of curiosity, wouldn't the master file be really compressible?

Not really -- good hashes act random.

Re:of course...

[Anonymous Coward]

LM passwords can only be 14 characters long. While this is pretty long, the LM password is actually broken into two separate 7 letter passwords. If the password is less than 8 characters long, the second half of the password will be 0000000.

In addition, all characters are forced to uppercase. So, you only have 26 letters + numbers + symbols = 68 possible characters. In the worst case, you have 68^7 = 6,722,988,818,432 possible combinations of hashes.

If you make a database of all of these hashes, it'll all easily fit on a single hard drive.

Re:of course...

[Spy Hunter]

You don't have to lug a database around, you set it up somewhere and access it using a web interface or something like that. A terabyte really is not that much information anymore; you can buy a firewire terabyte drive that you can hold in your hand (though it's kinda heavy) for $800. A hundred terabytes for the database with all special characters is probably out of reach for most people for now, but for a business it's no problem. And one terabyte for all letters and numbers is quite doable for any cracker who feels like it.

Re:of course...

[cratermoon]

> People aren't going to be lugging around terabyte-sized password database files.

Not this year, probably not next year. Sooner than you probably expect, though.

Re:of course...

[Corrado]

People aren't going to be lugging around terabyte-sized password database files.

But they wouldn't need to. All you need is a telnet client and a network connection. And there is no reason that one couldn't add to the existing files.

In fact, this would be a really cool project to break up into pieces. Bob takes everything starting with A|a, Steve takes B|b, etc... Then just build a front end (accessable via telnet) that passes each query off to each back end and returns the results. You could even hack together a simple Java client that would bang against an LM password file. Instant cracking tool - cool!

Re:of course...

[Jeffrey Baker]

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."

Re:of course...

[gl4ss]

.... or the guy could just lug around a mobile phone with a j2me telnet client and access some breaker elsewhere...

or do it later or whatever.

Re:of course...

[Anonymous Coward]

You can use the hash as the address in a file where the plaintext is. hash * 7, that is. Cuts the space required in half.

Re:of course...

[XMyth]

Of course, the portion of the master file with the password combinations would compress fairly well.

Re:of course...

[Albert Sandberg]

Famous last words! ;)

Re:of course...

[ckaminski]

Which just ignores the fact that you only have to have ONE valid password per hash in order to crack it. That password may be complete gibberish, but it'll still work to log you in untraceably.

Say there's 36 valid hash characters, then

36^7 which I calculate as:

78,364,164,096. 78 billion hash combinations.

78.3b * 7 = 548 Billion x 2 for character mapping

= 1.1 TB.

Plus some overhead

You'll be able to fit this on a laptop in 2 years.

Re:of course...

[B'Trey]

That's uncompressed. Since we're talking about regular sequences, they should compress quite well.

Additionally, it seems like there's a much easier way to do this. If you number the passwords and the hashes in sequence, you should be able to store a simple mapping. If the first password (the single letter a) hashes to the 1,367,429 hash, your first entry would be 1 -> 1367429, which takes considerable less than 14 bytes to store. Converting from the number back to the actual password/hash and vice versa shouldn't be that difficult. I'm too lazy and too busy to do the actual calculation but I'm quite sure this scheme would get you onto a single hard drive easily, and there are lots of other ways you could compress it even further.

Re:of course...

[Jeffrey Baker]

To make this of any use at all you need to be able to reverse from the hash to the plaintext in O(1) time, which certainly limits the cleverness of the available compression schemes. The one downthread which only stores the plaintext, in hash order, is smart but only reduces the storage by half. You couldn't compress the plaintext with that scheme, because then you wouldn't be able to address it directly (although you could probably compress it in chunks and record the real starting address of each chunk). Even if you did I'd guess you would have reduced the storage by at most a factor of 5, which still isn't anywhere near fitting on a solitary disk.

Re:of course...

[WNight]

Not really, you'd sort the hashes in order to make looking them up quick - this means that password 'aaaa' and 'aaab' would likely be half the file apart. In other words, too random for the compression algorithm to take advantage of. Of course, you're only going passwords which are letters+numbers, so that's only 5.2 bits of data per byte and will compress fairly well because of that, but not as well as a list of 'aaaa' 'aaab' 'aaac' etc.

Re:of course...

[Anonymous Coward]

LM passwords can only be 14 characters long. While this is pretty long, the LM password is actually broken into two separate 7 letter passwords. If the password is less than 8 characters long, the second half of the password will be 0000000.

You can use Windows policies to force users to have a certain number of number or special characters in their password, but I don't think you can enforce anything on the 7-character halves.

If the first 7 characters are alphabetic (people tend to stick the required numbers/symbols at the end of a password), you'll crack that half in 0.2 seconds and can probably brute-force the other one. The last half is probably shorter than the full length - an 8-character minimum length is common, leaving only 1 character in the second half (assuming people only use the minimum size), probably the required symbol or number.

Re:of course...

[aardwolf204]

While the security risk exists, good password design obviously minimizes it.

Good password design:
1. disable NTLM
2. use 15+ character passwords.
3. dont write you password on a post-it note and attach it to the bottom side of your keyboard

Re:of course...

[Anonymous Coward]

Of course if you sort by the hashed value the password part won't compress as well, but then the hash part will compress very well (since it's sorted, they'll start out 0000XXXX, 0001XXXX, etc).

Re:of course...

[operagost]

4. Don't use the combination from your luggage.

Re:of course...

[fdicostanzo]

no really.

the hashes themselves would be sorted, as you say. Therefore hash ab12fe="pass" would be right next to ab12ff="god" and the "ab12f" part would be the same.

its the same with dictionary words, only compressing the hash prefixes.

Re:of course...

[Robert The Coward]

I agree with disable ntlm but if you require your users to use 15+ character password I will bet you money it gets write down on a post-it note or some pice of paper and put somewhere at there desk.

Re:of course...

[aardwolf204]

how about these for some possible passwords:

1. your favoriate quote from a movie
2. something your mother always told you when you were young.
3. a passage from a book sitting on your desk, incase you forget you can just look it up and to anyone else it just looks like your reading a book.

who ever said a password cant be "i hate stupid users who dont know which one is a backslash" or "rent is due on the 5th of every month" or "dont forget to wash behind your ears".

Guess what: they're easier to type then 5gIw03nVBh... Trust me! It just takes a bit getting used to hitting space if your like me.

Bonus: using passwords over 15 characters long makes windows not store a NTLM hash anyway.

Rant: Now if only every system would accept such long passwords, I'm tired of systems that require 6 - 8 characters.

Re:of course...

[B'Trey]

Hardly. This isn't that difficult. Here's one scheme that immediately comes to mind. I don't know that it's the best one but it'll certainly work.

Lets say that password PASS hashes to 9Abz. We don't know that, of course, we just know that we have a hash of 9Abz and want to find out the password it represents. The first thing we need to do is to convert our hash to a unique number.

I don't know for sure how many unique characters there are in the LM hash output. The grandparent post which started this said 68, so I'll go with that. You therefore consider the hash as a number in a base 68 number system. 0 is 0, 1 is 1,..., 9 is 9, a is 10, b is 11 ... z is 35, A is 26, etc, including whatever punctuation and special characters are allowed. (It doesn't really matter what value you assign to which symbol, so long as you're consistent and you assign a unique value to each symbol, starting with a value of 0 and working up to 1 less than the base.) To convert a number from another base to base 10, you simply add the value of the least significant digit, multiple the value of the next least by the base, the third least by the base squared, etc. So if you have a hash like 9Abz, it converts to 35 + (11 * 68) + (26 * 68 * 68) + (9 * 68 * 68 * 68) = 2,950,895. (Essentially what we've done is hash our hash, but we do it using a reversible hash rather than a non-reversible one.)

You then go to your database and lookup entry number 2,950, 895. You find out that that entry is a base 10 number 328,551. You then need to convert that base 10 number into a base 26 number, using the symbols A through Z with a value of 0 through 25 respectively. To do that, you divide the number by 26 repeatedly, noting your remainders. 328,551 / 26 = 12,636 r 15. 12,636 / 26 = 486 r 0. 486 / 26 = 18 r 18. 18 /26 = 0 r 18. Write down your remainders: 15 0 18 18. Convert those numbers to letters using the A = 0...Z = 25 scheme. P A S S. We just converted the hash 9Abz to the password PASS. The mathematics is trivial and would take no time at all.

The time consuming part, of course, is populating your database. To do that, you simply itterate through all possible passwords. You hash the password, convert that hash to a number, convert the password to a number and store the password number in the location indicated by hash numbers entry. In other words, you'd hash PASS to 9Abz, convert 9Abz to the number 2,950,895 and convert PASS to the number 328,551. Then you store the number 328,551 in the 2,950,895th location in your database.

You'd end up with a database that contains GP posts 6,722,988,818,432 entries. Each entry contains a number that is at max 26^7, which can be stored in four bytes. So you're only storing four bytes per entry, not 14. Additionally, since you have 68 characters in the hash and only 26 in the passwords, most of those entries will be empty. There should be lots of clever little tricks to reduce the size further.

Re:of course...

[Anonymous Coward]

There are already 1TB firewire drives that you can hook up to today's laptops...

Buy two, they're small! (IIRC, those units were around $1000)

Re:of course...

[Anonymous Coward]

Those are still pretty weak passwords (especially quotes). Between social-engineering (oh, so you like Tolkien?) and text files on the net, it's easy to narrow down the possible universe.

One thing to think about... how many words to you know? How many do you use at least once per week? Odds are, you pull random passwords from a rather small (relatively) vocabulary. Most folks use around 10,000 words (or there abouts), but there are easily 300,000 words in english.

So by picking words yourself, you're only using 1/30th of the possible universe of words, and it's probably the same 1/30th that everyone else is using.

The best bet is to use a random password picker that randomly picks two or three words from a 300,000+ word list. Randomly capitalizes a few characters and tosses a few numbers into the mix.

Here's a list of 20 to get you started:

safflowers-mysidean+
unadjEctived+lanDo!
tarty&roustabout0
levisticum98affirmant=
advert$disbelieving$
baCktender$fiCation0
vampirizes&baroco0
runite17breedings?
morbify&nonescape-
invitinglypluma0
secTators%coloAless0
gratespreplaced%
voltagraphyprobridge0
augmentedLy69Aeri0
lactotoxin$depeinct!
sheernessargalis=
savoYed&enervaDe0
lautitioussalvings0
pRogeniture51opuGaster0
cahuillacuidado+

Re:of course...

[Froug]

No, definitely this year:
Lacie portable 1TB drive

Sooner than you expected, wouldn't you say? ;)

Re:of course...

[Froug]

15+ character passwords are overkill if you disable LM hashing, and you can bet your booty they'll get written down. Using current hardware, cracking 8 characters with numbers and punctuation will take far longer than the default NT password expiry interval.

A phrase rife with numbers, punctuation and intentional (or un-) spelling errors would be a long password that also serves as a mnemonic to aid in memorization... but if your system requests your password frequently, then such a passphrase would be very tedious to enter each time.

Re:of course...

[bill_mcgonigle]

Not really -- good hashes act random. ?

You wouldn't want to use an LZ-type compressor - sort the hashes and store the database as a trie, for example.

Sorting might take a while, but we're talking KGB here.

Re:of course...

[Anonymous Coward]

True, the social engineering thing comes into play, thats why I use made up words sometimes, and google them to make sure they are 100% original first. Or just mis-spelel a word or two. Then again it doesnt matter how long or short, simple or complex your password is if you write it down and give it to your secratary, or give it out in exchange for a chocolate bar.

LM Hash

[cube00]

Mwaha my roomates shall fear the LM Hash database I now control! UNLESS one of them is funky enough to make a 16+ character password :) User name : Admin Password : ****************

Re:LM Hash

[Spy Hunter]

Doesn't matter how long the password is, LM hashing splits it up into nice bite-sized 7-character segments to ease cracking.

Re:LM Hash

[flosofl]

It's my understanding that passwords greater than 14 chars are only hashed using LMv2(at least in XP/2000/2003). Only passwords with 14 or less characters are hased with LMv1 concurrently with LMv2 - why use v1 at all? Does this splitting apply to both versions of LM?

Of course, I could be wrong. I use mostly *NIX at work and home. Just minimal exposure to MS.

[sarcasm]Being slashdot I'm sure that where I am in error will pointed out in a polite and respecful manner.[/sarcasm]

Re:LM Hash

[Spy Hunter]

You're right; I realized that's what he meant just after I pressed "submit." Guess I didn't hit back soon enough to prevent the post, though.

LM definition

[jbeamon]

LM = Lan Manager in older Windows environments. LM was known to be a bit weak on password hashing. Though I can't reach the site to read the actual article, I'm going to bet my first-productive-post ranking that this is Lan Manager.

Re:LM definition

[Anonymous Coward]

Given the sheer numbers of Windows '95, '98, NT (both server and workstation), and 2000 (by default it's on) machines I'd say this still has a good shot of working. I doubt that there are that many shops that are Windows 2000/3/XP only both server and desktop that have *NO* legacy systems.

Even when our company goes to Windows 2000/3 I seriously doubt anyone will even *think* about changing any of this. I'm the only one here that even has a clue about this kind of stuff, and with the legacy equipment there's *NO WAY* we'll be able to go past LM hashes for at least a couple of years (read 4-5).

Windows security is fun no? :)

Re:LM definition

[AndroidCat]

Did IBM ever remove Lan Manager from OS/2?

Better than I thought

[Anonymous Coward]

So, in other words, as bad as LM is, my current passwords would still be basically safe if I were using LM? (My passwds are 8 chars, and include upper and lower case letters, numbers, and punctuation.)

That's actually doing a lot better than I thought.

Re:Better than I thought

[zaffir]

You're more safe, but not by much. LM hashes are forced to uppercase and are split into two 7 character hashes. If your password is 8 characters, we only have to crack a 7 byte has and then a 1 byte hash. This doesn't take that long.

Re:Better than I thought

[Zardus]

LM Hashing converts all lowercase letters to uppercase, so the casing won't do you much good, but your numbers will, yeah. The length also won't do you much good, since the hash function will just split the password into two strings (a 7-char and a 1-char) and hash them seperately.

Re:Better than I thought

[Anonymous Coward]

Unfortunately, the password is sectioned up into 7-character parts. After 7 characters, you're only increasing complexity linearly since each section can be cracked individually. That 8th character would be cracked in microseconds after the front 7 chars.

Re:Better than I thought

[Froug]

The case of the characters is of no consequence because the LM hashing algorithm converts everything to uppercase. If the trend in L0phtCrack's figures continues for the 3rd column in the LM hash table, we can expect that the 7-character mark will be cracked after a total of around 10-11 days. Characters beyond the 7th will be trivial due to the way the LM hashing scheme carves up the password into 7-character chunks. At best a 14-character password would only double the time required, rather that cause it to continue rising exponentially.

So no, you're not very safe. A couple weeks is a rather short amount of time for a brute force attack, and that can be drastically reduced by using beefier or distributed systems.

Re:Better than I thought

[NicenessHimself]

Why take twice as long? Surely for each hash chunk you have to crunch, it is just an extra compare? You don't need to rehash every possible password to for each chunk..

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:Non sequitur?

[PitaBred]

I beleive it means that you can make a lookup table relatively cheaply, rather than having to generate it on demand, and thus greatly speed up the LM hacking.

Re:Non sequitur?

[stray]

it's all about a time/space trade-off:

- you have a password hash you want to crack

you can either:

- brute force your way through a long list of possible passwords to find one that matches the hash; everytime you do this, it takes a lot of time and processing power

- or you can go through all possible passwords ONCE and save the resulting hashes; subsequent cracking jobs are very fast, but you wasted a lot of space to store all possible hashes.

thus, if disk space is cheap and you can afford to keep a couple of gigs in pre-computed hashes around, you have a very fast way of cracking weak hashes. a couple of years ago, this was not possible due to hard drives being like 200MB large.

Re:Non sequitur?

[xstonedogx]

No, it's not a non sequitur.

For it to be a non sequitur the author would have to have intended one point to follow the next. (ie: Disk storage has increased (therefore|so|but) blatant insecurities in hashing have not gone away.)

The author isn't drawing any conclusions in that statement. He's stating two facts that both make the letters only LM hashes easily exploitable via flat files.

Re:Non sequitur?

[mikael]

- or you can go through all possible passwords ONCE and save the resulting hashes; subsequent cracking jobs are very fast, but you wasted a lot of space to store all possible hashes.

thus, if disk space is cheap and you can afford to keep a couple of gigs in pre-computed hashes around, you have a very fast way of cracking weak hashes. a couple of years ago, this was not possible due to hard drives being like 200MB large.

You could always burn the data on a DVD rom. That would give you around 7 Gigabytes to play with. For a box of ten DVD's, that around $10 to $20 for 70 Gigabytes. And you could always buy second hard disk drive. Even Dell sells home PC's with hard disk drives in the 250 - 400 Gigabyte size range. And laptop sized hard-disk drives are now in the 120 Gigabyte range.

Re:Non sequitur?

[Anonymous Coward]

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

You didn't RTFA, did you. The entire article was discussing how those two parts of the sentance relate.

Re:What is an LM hash?

[Anonymous Coward]

http://en.wikipedia.org/wiki/Lm_hash

And why do I care?

[seebs]

Who or what uses "LM hash"? It'd be nice to have an example application or two.

Re:And why do I care?

[duffbeer703]

LM as in NTLM... which means that old-style NT Authentication will be going away soon.

Re:And why do I care?

[Reducer2001]

Windows NT for sure, I believe Win2k does by default, but you can turn it off.

Re:And why do I care?

[XMyth]

This wont' speed the death of NTLM at all. You could crack them in a few hours before....not much has changed really.

Re:And why do I care?

[Foolhardy]

LM != NTLM. The article is about LM which is used for network compatibility with DOS, Lan Manager, and Win9x. NT has always supported NTLM.

Re:And why do I care?

[m50d]

There's this minor OS from Redmond that has a small but devoted following...

LMv2

[echocharlie]

By default for backward compatibility many Windows flavors use LMv1. LMv2 is a little more secure, but you need to enforce strict usage of it for it to be effective.

Re:LMv2

[Anonymous Coward]

By default NT sends both LMv1 and LMv2 hashes
over the network for backward compatability.
So while LMv2 is more secure, you can also
view an LMv1 hash for the same password.

Hence, the suckage of donkey balls by M$.

Re:What is an LM hash?

[bunnyman]

Windows generates and stores user account passwords by using two different password representations, generally known as "hashes." When you set or change the password for a user account to a password that contains fewer than 15 characters, Windows generates both a LAN Manager hash (LM hash) and a Windows NT hash (NT hash) of the password. These hashes are stored in the local Security Accounts Manager (SAM) database or in Active Directory.

The LM hash is relatively weak compared to the NT hash, and it is therefore prone to fast brute force attack.

Source: http://support.microsoft.com/default.aspx?scid=KB; EN-US;q299656

Re:Please explain

[rkhalloran]

RTFA, but quickly, LM hash (Lan Manager hash) is the older MSFT scheme for encrypting passwords. It's been known as insecure for some time, but thought to take an fair amount of time to crack. This saves the problem; take the hashed PW, run it through this site and recover the password.

modeling unknown passwords

[strook]

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 think this sort of attack could get much stronger than people expect if there was some sort of Markov-process-ish way of generating plausible passwords. I mean, if Google can guess when you spelled something wrong, these programs should be able to figure out which strings are more likely to be passwords. Or maybe I'm overgeneralizing by how I pick my own passwords....

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?

Re:modeling unknown passwords

[XMyth]

Perhaps we'll need to move to Write Only Memory (http://www.hyperdictionary.com/computing/write-on ly+memory) that only the CPU has access to.

(c:

Re:modeling unknown passwords

[amorsen]

Your example "foo7bar+" is pretty easy to crack. LM breaks passwords into 7-character parts, so you just need to break "foo7bar", which is reasonably easy to do, and "+", which is trivial. (Yes I had my password broken this way once. I kept the complexity at the end. Bad move. Now I know better.)

Re:modeling unknown passwords

[jonfelder]

I'm not sure why this modded insightful. The point is that with this method you can crack all passwords containing just letters instantly. The obvious extension of this is building hash tables that will allow you to crack all passwords instantly. The space to contain those hash tables is not quite within reach of the average cracker yet...but it most certainly will be sooner or later.

If you want a program that figures out which strings are likely to be passwords, use l0phtcrack which incorporates a dictionary attack. I believe it will also do hybrid dictionary attacks which appends and prepends various characters to the words. I'm not sure if it does substitutions or not...other programs do however.

The success rate for these attacks is high, but not 100% and not virtually instantaneous.

Re:modeling unknown passwords

[angryty]

LC5 from @stake is doing this already with their L0phtcrack program (LC5).

They ship their "Admin" version with hashes of "trillions" of alphanumeric English password combinations.

If you bought the "Pro" version and had access to the hashes already it wouldn't do you any good - they've disabled the functionality :-(

The hash files take up 2 CDs.

Re:modeling unknown passwords

[shrikel]

much less likely password

Yes, much less likely, but people sometimes choose things like that for their passwords anyway. My wife's self-chosen password to her bank account, for example, is 'Nfok3G!~qOmp', and I can tell you that NOBODY is going to guess that one!

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.

Re:modeling unknown passwords

[Anonymous Coward]

...and I can tell you that NOBODY is going to guess that one!

Yeah, ha ha ha, you're right. That's a really good password and you're smart....

....

Hey, what's your wife's social security number?

Re:modeling unknown passwords

[Anonymous Coward]

We already hide the hash file(at least, some of us do). Eventually we will have to move away from memorized passwords. Options today include biometrics and large passwords stored on pen drives.

Re:modeling unknown passwords

[babyrat]

hmmm not sure who or what Markov is, but there's an old password cracking tool called Crack that read a dicitonary of standard words and allowed you to define rules to modify the words. ie you could have a rule to append '1' to the end of each word, or concatenate two 4 letter words, and then insert a numeric between them (ie take run and fun and create run4fun.)

used it back in the uni days

Re:modeling unknown passwords

[bill_mcgonigle]

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

It's too bad this idea wasn't around when Microsoft was designing LanMan. Oh, wait , Unix has had it for 20 years.

So unix passwords are only 4096 times harder. We'll have that kind of storage in about a decade, so it's time to start getting bigger keyspaces.

The description is a bit vauge

[vespazzari]

Wow, that was brilliant, 0 comments and that machine is going up in flames.

John the Ripper

[Anonymous Coward]

I use john the ripper to decrypt passwords, could this potentionally replace jtr? Because wouldnt i just have to take the passwords I was going to have john the ripper decrypt and send the hashes to the telnet server mentioned in this article?

I cant look into it more right now because im at work, but I will try to figure out at home unless someone can give me an answer.

Look logs

[Anonymous Coward]

Geez lets hope they are not logging password lookups vrs IP addresses Mwhahahahahahahah

Web seems slow today, here is a mirror:

[Anonymous Coward]

http://www.dealsites.net/wrap.php?file=beginningto seethelight.htm

Wikipedia is your friend.

[Anonymous Coward]

"NTLM" at Wikipedia

It is used, among other things, for Active Directory authentication.

My passwords

[nuggz]

I tend to use 6-8 characters.
Numbers, upper and lower case letters.
so 62^+62^7+62^8 =2.12x10^14 combinations.
I think I'm okay for a while.
Multicase passwords do HUGE things to the statistics of the problem.

Re:My passwords

[Mike Whitney]

Except that, IIRC, old LM hashes are case folded. I which case, you're looking at:

36^6 + 36^7 + 36^8 ~= 2.9e12

which is still big at 6-8 bytes per entry, but not all that bad.

Re:My passwords

[Anonymous Coward]

But not in an LM hash...everything is translated to upper case....

Re:My passwords

[kidgenius]

Multicase passwords do HUGE things to the statistics of the problem.

Normally, yes. But the LM method converts everything to uppercase before hashing. So your 8 character password, that had 10^14 combinations has just been reduced down to (26+10)^8... combinations or 2.9*10^12. Now, you might be saying "That was only a factor of four drop, no big deal, still 10^12 combos left. Realize though, that this DB currently has all possible passwords of a maximum length of 15 characters. This is 2.8*10^13 combos. This is less than the 10^12 possibilities that your password has. Consider that it searches in 0.2 seconds, and your password is not so safe.

Re:My passwords

[DBA_01123]

If LMv1 hashes are enabled then a *case insensitive* hash of your password is there to be matched against. Even if the server isn't using them having them there at all is a HUGE hint as to what your password is. Find a match for the case insensitive hash then work through the possible case permutations of it till you get a match for the case sensitive hash. It's several orders of magnitude easier than directly going after the case senstive hash.

Re:My passwords

[delta407]

Multicase passwords do HUGE things to the statistics of the problem.

That's why Microsoft's LM hashing algorithm is so cool -- it uppercases your password before hashing. With this algorithm, multicase passwords do nothing to the statistics.

I think I'm okay for a while.

You're okay for about 2 hours and 34 minutes: that's how long it takes to traverse every possible alphanumeric input on the author's test rig. Additionally, the article suggests that tables including every possible LM hash for [A-Z0-9] would occupy only 1.2 TB of space, meaning that these lookups could be done in a matter of milliseconds instead.

Re:My passwords

[Pete (big-pete)]

I tend to use 6-8 characters.
Numbers, upper and lower case letters.

I tend to use uppercase, lowercase, numbers, and punctuation. An example might look like: s1mhm$tM-BIdc! (just off the top of my head, and memorable to me)

Most people do have horrific password security though...

-- Pete.

Re:My passwords

[Anonymous Coward]

That's only 2^48. Nothing unbruteforceable.

Re:My passwords

[Anonymous Coward]

I think I'm okay for a while....Multicase passwords do HUGE things to the statistics of the problem.

You didn't RTFA, did you. They discussed the mixed case and how the length is broken up. Your math assumes a perfect hashing algorithm. Your computer doesn't use a perfect algorithm, making your stastics pretty worthless.

Re:My passwords

[Anonymous Coward]

Actually, the LM hash reduces every password to two seven character chunks.

quoted from http://www.microsoft.com/technet/security/secnews/ articles/itproviewpoint091004.mspx

The LM hash is a very weak one-way function used for storing passwords. Originally invented for the LAN Manager operating system, the LM hash was included in Windows NT for backward compatibility. It is still included for backward compatibility. Because of the way the LM hash is calculated, no password with an LM hash is stronger than a 7-character password selected from a 142-character character set.

Re:What is an LM hash?

[Tony Hoyle]

It's what Windows used to use to do authentication (NTLMv1). They improved on it a while ago (NTLMv2) but still transmit the LM hash by default in all authentication - basically rendering the security of NTLMv2 completely useless.

I used to piss off the admins where I last worked by runnig L0hptCrack over their tightly secure network and telling them the admin password every time they changed it :) Luckily I was high enough in the company to get away with it (I was authorised to know the password anyway... just more fun that way).

You can and should switch this off unless you're using just a home LAN (beats me why it isn't off by default). Even better upgrade all your network to at least Win2k then disable NTLM entirely and use kerberos (samba 3 can be a full kerberos domain member).

(FYI: See:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\cont ro l\LSA\LMCompatibilityLevel

A value of 0 (the default) means you have no security.

Change it to 3 on your clients, or 5 on your Domain controller)

This just in from beginningtoseethelight...

[jmcneill]

Dear Slashdot Readers,

Thank you for letting us know your passwords.

Regards,
The staff of beginningtoseethelight

Re:This just in from beginningtoseethelight...

[Anonymous Coward]

All your passwords,

are belong to me.

Daryl

Re:What is an LM hash?

[Anonymous Coward]

Here's another (more in depth) explanation.

lookup table vs computation

[sczimme]

Instead of using the brute-force computing approach of generating hashes and comparing them to the known hash (looking for a match), this process uses an already created list or table of passwds and their associated hashes. Creating the table is computationally and storage[ally] non-trivial, but once it is in place cracking a passwd is as easy as grep-ing through the list/table to find the known hash.

Nutshell:

cracking passwds individually: no up front work and extremely variable cracking time

creating the database: lots of work up front but dramatically reduced cracking time

The lookup approach is extremely helpful for large numbers of hashes; if you have only one or two hashes, the brute-force method probably makes more sense.

Re:lookup table vs computation

[Anonymous Coward]

# cracking passwds individually: no up front work and extremely variable cracking time
# creating the database: lots of work up front but dramatically reduced cracking time

And just as importantly:
# cracking passwds individually: Requires lots of math and encryption algorithm stuff; and requires a weak hashing algorithm.
# creating the database: Anyone can do it, because they give you the forward hashing code.

So can anyone way where these hashes are stored on a Windows machine? It'd be interesting to see if the windows boxes here have the weak hashes enabled (we're not really a windows shop, but have a few lying around).

RTFA, eh?

[andyrut]

LM is a password-hashing scheme used in Windows. Read the first paragraph of the linked article:

This article is based primarily on a local default setup of NT5.0 Professional or 2K (Windows 2000), however there maybe additional verified references to XP Professional and Server Editions. Much will apply across the NT range, but not all has been verified.

Light?

[alapalaya]

in the article:

beginningtoseethelight.no-ip.org

the /. fortune:

The light at the end of the tunnel is the headlight of an approaching train.

Am I the only one to see a connection ?

Re:What is an LM hash?

[jfengel]

LM = Lan Manager, the Windows 95 way of handling network passwords.

hash = a way of storing passwords without leaving the password on the disk. You encrypt the password into a hash code and store that instead. You can't unencrypt it to derive the password but you can check a password guess by encrypting the guess the same way. If the guess hash == the password hash, you get in.

The best part is, you don't have to keep the hash code a secret, because it's not the hard part. You're not asked to provide the hash value; you're asked to provide something that hashes to the value. So you can store it on the disk and even send it out over the LAN where it can be sniffed.

That's very convenient: you can cache the hash code on every computer without having to trouble the central server to do the work. You don't want to send the password over the network (where it could be sniffed); nor is sending the hash code to the server for verification (because that could be spoofed). You distribute the hash to each computer, then let it decide if the password guess is correct. The password never goes across the network.

That works as long as you can't decrypt the hash. But if you work long enough you can just brute force it: just run all the passwords until you come up with the one that hashes to the same value. And you can do it offline: you take the hash code back to your own computer(s) and do the brute force there. You're not sitting in front of the computer you want to hack.

The old LM hash code was relatively short; ten years ago when it was developed disk drives were much smaller. Now a combination of big disks and big processors (and clever algorithms) make it possible to brute-force it.

The thing is, Windows NT and later use NT hashes instead, which are more secure. But for compatability with Windows 95 and 98, by default they also store the LM hash code. Which means that your password is sitting on a visible place on the disk, encrypted in a way which is readily reversible to modern hackers.

That's been true for a while, but this new hack makes it trivial to decrypt; it used to take hours.

Mirror.

[donniejones18]

Mirror...let's see how long I last.
LM Hash

my favorite password

[Anonymous Coward]

AAD3B435B51404EEAAD3B435B51404EE

In related news..

[Tracer_Bullet82]

ElcomSoft will release All Known Passwords v1.0 in two weeks.

Guess the password

[Evil Butters]

Gee, for Windows users, I could probably guess the password in three tries and be right more than 50% of the time (much faster than trying to query a slashdotted online DB). Hint: it's probably: password admin [blank] - no password

Re:Guess the password

[m3j00]

yeah d00d those windoze lamerz can't think of original passwerdz cuz there so dumb lol idiot

Re:Guess the password

[Anonymous Coward]

or qwerty

Re:Guess the password

[Anonymous Coward]

Remember, the normal user is usually a slow typer. Thus, in their minds: why bother typing "password", when you can type "pass"?

awright!

[sootman]

now we're gonna kick it old-skool and /. a telnet server! woo hoo, just like the old days! our next target: gopher://sunsite.unc.edu

Re:awright!

[ckaminski]

Remember when browsers could understand gopher:// ?

Re:awright!

[benploni]

Remember when browsers could understand gopher:// ?

Konqueror still does (by default!). Behold the wondrous power of KIO plugins!

Re:awright!

[Anonymous Coward]

So do Mozilla / Firefox, the rendering wasn't quite perfect last time I tried it (e.g. "Index of ..." left over from FTP-view) but it does work.

Re:awright!

[Anonymous Coward]

Not setting up a web page is an interesting way to filter who will use the server.

W0rmage.

[Anonymous Coward]

Can't wait till the first worm comes around that use this DB to crax0r its way deeper into networks.

Re:W0rmage.

[ValuJet]

1.2 terrabyte worms will definitly be a thing to fear.

Whew! I'm still safe

[DongleFondle]

I guess I'm still relatively safe though because my admin password is not only 10 characters long, but has capitals, lower case, numbers and symbols in random order.

Its H82sd*e2Tn.

Nobody is ever going to crack that!!!

Disable LM Hash

[mixmasterjake]

Unless you have machines on your network running 95/98 you should disable LM Hash in Windows. It is there only for backwards compatibility and you can disable it easily:

http://support.microsoft.com/default.aspx?scid=KB; EN-US;q299656

Re:Disable LM Hash

[L-Train8]

Yes, LM hashed passwords have been insecure for years, since L0phtCrack came out. Since then, as processor power has increased, it has only gotten quicker to crack passwords.

If you have 95/98 machines on your NT or 2000 network, your passwords are not secure, period.

Re:Disable LM Hash

[Anonymous Coward]

You can also install the Active directory client extensions for win 9x. Course that's a bandaid fix more than anything considering win 9x security.

Re:Disable LM Hash

[mdielmann]

I don't consider any task that warns that doing it incorrectly may require me to reinstall my system to be easy. Note that of all the options listed, only one (local security of Active Directory for WinXP and later) can be done through a dialog. Neither easy, nor clean, although it's not something I haven't done before. Granted, modifying many Linux settings is no easier.

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.

Re:Hashes

[fatmonkeyboy]

Storing two hashes isn't worthwhile. At best it can only double the amount of time taken to come up with a matching password.

Might as well just check the SHA1 hash. You won't gain anything by checking the MD5 hash as well.

Re:Hashes

[chgros]

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
I we think MD5 is too weak, we have to move to a stronger hash. MD5+SHA1 is not necessarily the best replacement.
Would there be any string of data which held the same hash for both MD5 and SHA1?
If you mean that 2 strings can have both the same MD5 ad the same SHA1, given the space of hashable data is at least as big as the space of hashes (actually, it's infinite vs finite), then answer is definitely yes. The question is, how hard is it to find a collision?
If you mean that a single string happens to hash to the same thing with both SHA1 and MD5, I don't know if this is possible, but in any case it's irrelevant.

Re:Hashes

[drew]

Would there be any string of data which held the same hash for both MD5 and SHA1?

yes there would. an MD5 hash is 32 hexadecimal digits, or 16 bytes. i'm not sure off the top of my head if SHA1 is the same, but for purposes of argument we will assume that it is. (regardless, it is a fixed number of characters from a finite set of possible characters, which is the main point here.)

so if we combine an MD5 hash and an SHA1 hash, we have essentially a 32 byte signature. Now if you are only using this to store passwords, and you arbitrarily define a password as a string of no more than 20 characters from a standard 104 key keyboard, then it is possible (although not guaranteed) that each of these passwords will have a different representation in your hashing scheme. however, if we are using this to store signatures of data which can be of arbitrary length, and of any character set, you are trying to map a finite (in this case (2^8)^32) number of signatures to an infinite number of possible data strings, so there will be collisions. an infinite number of collisions, actually.

no fixed length hash can map to an arbitrary data sequence without there being collisions. the point of a well designed hashing algorithm is to make sure that collisions never happen for data that is similar. (e.g. in a perfect hashing routine, no two ten character alphanumeric strings would collide, but a ten character alphanumeric may produce the same hash as a 10mb jpeg file.) this makes it much harder to brute force a hash, as it reduces the number of collisions that are actually useful. (e.g. a 10 mb jpeg file with the same hash as a 10 character password is useless to an attacker.)

Re:Hashes

[Anonymous Coward]

no fixed length hash can map to an arbitrary data sequence without there being collisions. the point of a well designed hashing algorithm is to make sure that collisions never happen for data that is similar.

Is this even possible for any sequence length with more information thant he hash? For example, given an n-character hash, you're guaranteed to have a collision in all sets greater than n (counting rule).

Re:Hashes

[zaffir]

Think of it this way.

Let's say your has is two bits. Freakishly huge, i know. You have four possible combinations for this hash - 10, 01, 11, 00.

Let's say A hashes to 10, B hashes to 01, C hashes to 11, and D to 00. What happens when you hash E? It has to be one of those four. Therefore you get a duplicate.

You can't have an infinite number of possibilites correlate to a finite number of hashes without overlap.

Re:Hashes

[m50d]

Bruce Scheiner explained this much better than me, but basically, that's not a good idea. There would be such strings of data, just as there are for any single hash, and because the MD5 and SHA1 algorithms are derived from a common root, they would be more common than the amount of data you're storing would suggest. You're better off modifying SHA-1 (the more secure of the two) to produce hashes of a length equal to the sum of both types of hashes, that would be more effective. If MD5 and SHA1 had nothing in common, this would be a valid approach, but still no more effective than a double-length SHA1.

Re:Hashes

[Anonymous Coward]

MD5 is typically 128bits (I think, by definition, it can't be anything else).

SHA-1 is usually 160bits (dunno if it can be anything else)

Might also be SHA-2 which can be longer (256bits?)... but I don't have that handy.

The short answer is that password storage systems need to use "salt" to store the hash. Microsoft's doesn't, which makes it weak. Even with a simple 8-bit "salt" applied to every password (every system has a random 8-bit "salt") increases the complexity and size of the lookup table by 256x (so now instead of 1TB to store all possible values, you need 256TB).

Most unix systems use salt when storing passwords.

Re:Hashes

[Anonymous Coward]

Yes, agreed. My question is whether or not it's possible to have a hashing algorithm for an arbitrary bit length greater than the hash that does not collide. I think I read the original post (or the first child) to read that it was possible to create a hash algorithm of n bits that could create a non-colliding hash of n+x bits.

Re:Hashes

[zaffir]

And my point was, no, you can't do that. No matter how you slice it, you can't put 5 liters of water in a 4 liter bottle.

Re:Hashes

[drew]

Well, there is no "perfect" hashing routine, there are only "more optimal" hashing routines. As to whether it is possible to design a hashing algorithm which ensures that collisions do not occur for similar data, it depends on how you define similar data. If you consider "similar data" to be, for example, any two strings of ASCII characters that are 40 characters long, than a 32 byte hash will not be able to hash all of those values without collisions, as you are trying to map 280 bits of variation in the input to 256 bits in the hash.

However, a hash can (in theory) be designed such that starting with one piece of data, say a 40 character ascii string, and changing one discrete part of that data, like changing lol to :-), will result in a significantly different hash.

The point to this goes beyond just avoiding collisions. It also protects against educated gueses. If we had a weak hashing algorithm, where the strings "hello" and "Hello" hashed to very similar values, it would be easy for a hacker to narrow down the search. Rather than having to brute force the original data (or a collision) an attacker would only have to try random data until he got a hash close to the one he was attacking and then try small variations until he arrived at the original key.

How long until...

[rewt66]

beginningtoseethelight gets hit with a DMCA lawsuit?

And, yes, I am aware of the irony of posting this on election day in the US...

Re:Please explain

[Not_Wiggins]

Even worse, take the hashed PW, run it through the site, and if it DOESN'T return the password, you've already eliminated a large chunk of possibilities from your (next step) brute force attack.

Now, admittedly, it would still take ungodly long time to crack all the next possibilities, but it does save SOME time.

This also makes one wonder if the next generation of password cracking is to distribute the terrabytes of pre-digested passwords across multiple systems so that you have the "numbers only" database, the "upper and lower case letters" database, etc; let multiple crackers/hackers share their efforts in a similar way.

Or... err... maybe I shouldn't have suggested that in a public forum. 8D

Microsoft's response?

[gargonia]

I wonder how long (if ever) it will take Microsoft to respond to this by releasing a patch (hopefully listed as a "Critical Update") to disable LM password hashes by default. I've wondered for years why they haven't already done that, but if they don't do it now then they're really asking for trouble.

It's interesting that a company that claims to be highly focused on security could let such a blatant hole sit for this long. When will they learn? Microsoft is best at making software, not operating systems. They should stick to what they do best and let the OS market go.

Re:Microsoft's response?

[ckaminski]

Because Microsoft's Customers have "DEMANDED" this feature. That Windows95/98 machines can interoperate in an NT Domain/AD regime.

So blame the 4 million corporate asshats who continue to run Win9x and won't cough up the money to upgrade to XP. You think Microsoft hasn't TRIED to make this problem go away?

Re:Microsoft's response?

[gargonia]

They don't have to eliminate the LM hash completely, just turn it off by default. Corporate asshats who choose to turn on and use LM hashes so they can join 9x machines to a domain take the security of their networks into their own hands.

Besides, if they can afford to refuse to provide hotfixes for Windows 2000 and 98 users for holes they are fixing in XP (most notably IE!) then why can they not afford to make a stand on this issue, which affects the security of the whole Windows family of OSes? Your explanation does not amke sense to me.

Re:Microsoft's response?

[Anonymous Coward]

Because Microsoft's Customers have "DEMANDED" this feature. That Windows95/98 machines can interoperate in an NT Domain/AD regime.

So blame the 4 million corporate asshats

Those corporate managers only "demand" this feature because Microsoft tells them that they are "secure".

If Microsoft told our CEO that, no, interoperability between 98 and 2000 is not secure, he would get rid of the 98 systems immediately. Howver MSFT continues to say you can interoperate, and he continues to believe them - no matter what his IT staff tells him.

How long before it's a Web-Service?

[Nom du Keyboard]

So how long before this becomes a Windows.NET Web-Service? Then all the hackers can struggle with Visual Studio .NET 2003.

Re:Non sequitur? I think you mean...

[Nom du Keyboard]

a couple of years ago, this was not possible due to hard drives being like 200MB large

I think you mean 200GB.

Torrent?

[slavemowgli]

Cool. Now, where's the .torrent that allows me to download those files? :)

Re:Torrent?

[psbrogna]

It might be quicker to generate than to download via bt.

Re:Torrent?

[slavemowgli]

May be. A download of 120 GB would take something 8 days, 16 hours and 20 minutes for me, assuming an average download speed of 160 kbps; I can get a bit more (up to 180 kbps), but BT usually doesn't reach that. No idea how long it would take to compute all the hashes myself, though. I'd try and see how fast l0phtcrack runs on my box, but I can't quite afford it. Damn greedy bastards.

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 ..

You're a Canuck, eh?

[Anonymous Coward]

n/t :)

Clear writing is a lost art...

[NotQuiteReal]

If the article were written more along these lines;

It is well known that the LM (LanManager password) hashing technique used by older Windows OSes (thru WinMe) is insecure. Now someone has really pointed this out by simply saving all possible password hashed in a database made possible with today's cheap, large disk drives...

But that wouldn't be nearly as much fun - by being vague you get many more posts correcting grammar, explaining what should have been there in the first place, etc.

In short, better writing might promote more useful comment posts, and we wouldn't want that on Slashdot.

Holy Ratshit, Batman!

[deacon]

That's why Microsoft's LM hashing algorithm is so cool -- it uppercases your password before hashing. With this algorithm, multicase passwords do nothing to the statistics.

Please, please tell me you are joking.

I am no fan of MicroSoft, but come on, no one would really do something like this.

I figured that my passwords are safe because they are normally the tunes of music..

For example

Taaaah-dum+dum*dum#dum#taaaaah|dum!tum^du m$tum%rumtittytum.

And since I am tone deaf, It's not very likey that someone will hit upon the combination soon.

The usage of the +-@# characters is based on a matrix written in pencil on the side of the monitor.

8^)

Re:Holy Ratshit, Batman!

[amorsen]

LM hashes every 7 characters separately, in order to lower the Total Cost of 0wn3rship.

Re:Holy Ratshit, Batman!

[Oestergaard]

He is not joking. And he didn't tell the whole story either; there are several either tremendous stupidities in the LM hash which makes long passwords worthless, and relatively short ones easier to break than their length would otherwise indicate (separate grouping of characters, triple-DES'ed *independently*).

The fun part is that any default install of Windows (at least up to and including XP) will send out the current users LM hash if he tries to connect to a SMB share.

So, if someone placed a link on their homepage to a patched Samba which logged LM hashes, they could gather LM hashes from most of their windows using visitors.

This would *include* those behind many firewalls, because many default firewall setups will allow *outgoing* connections - and in this particular case, it is indeed the windows client that is initiating the connection to the remote web server in order to send away the current users LM hash (along with username, domain, local machine name and other goodies).

Yes, I told CERT about this some three years ago. They wouldn't touch it with a five foot pole. I then told Microsoft about it. Their response was something like "fixing that problem would require us to re-design our windows networking layer - therefore it is not a security problem".

Well, there you have it.

But hey, if you're on Windows you're fucked anyway, and none of this should really come as a shock to you :)

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:Holy Ratshit, Batman!

[radish]

This is all very true, and I won't try to defend it. But, and this is a big but, does it really matter if some guy on a remote website gets my password? First, my IP is dynamic, so they're only going to have so long to attack before I vanish. Second, they have to get through my firewall. I have no ports open to incoming connections. Then, they're going to have to find a useful service which they can use the password with. Seeing as my SMB shares are all on non-routable interfaces I'm not sure how easy that is.

So basically, my windows admin password is only useful to someone sitting at my machine, or, at a push, sitting on my LAN. And this guy isn't....

Re:Holy Ratshit, Batman!

[SydShamino]

>> The fun part is that any default install of Windows (at least up to and including XP) will send out the current users LM hash if he tries to connect to a SMB share.

So, can you post a link explaining how to disable this as part of a non-default install? I'm not sure I've ever seen this before.

Re:Holy Ratshit, Batman!

[Oestergaard]

Assuming the average user does not re-use passwords on multiple systems, that there is no wireless, and that the attacker won't simply automate the attack to log in (if possible back thru the firewalls) next time the user visits.

Sure, then you're sort of right I guess :)

Basically, you're safe because you're one fish in a million. The chance of getting eaten is very small.

Unless you're not just a little fish - if someone keeps a database of LM hashes (and user name, domain, machine name, IP, ...) it should be pretty easy to narrow down on, say, '\\whitehouse\dubya', and then suddenly there is incitement for the attacker to actually spend some effort on finding uses for the password.

Re:Holy Ratshit, Batman!

[deacon]

This is all very true, and I won't try to defend it. But, and this is a big but, does it really matter if some guy on a remote website gets my password?

So what you are saying is, It's ok that my condom has a hole in it, because I am not going to get laid anyway?

Re:Holy Ratshit, Batman!

[deacon]

But hey, if you're on Windows you're fucked anyway, and none of this should really come as a shock to you :)

Well, I really have a VAX mentality, so Linux is a reasonable substitute for me.

My tiny brain just boggles at the fact that things were done this way...

I don't understand how someone could decide that the least secure path was the right one. What was being saved/conserved?

Time? Money? What!

Re:Holy Ratshit, Batman!

[radish]

(if possible back thru the firewalls)

This is the bit I don't get. Seriously, if I have a firewall with no open ports, even with my IP, share name and admin password I can't see what you could possibly do. You can't connect to the share, the firewall will block your connection. Not only that, the IP you have is my external IP, my actual boxes are on a private (NAT) subnet, so you have no idea which of those to hit. You can't even see my actual machines, because private addresses are not routable. So how does my password help you?

Look at it this way, remember all those cracking competitions we used to see? Where a security firm would put a box on the net and let people go at it? They usually supplied the root password, but were confident in the fact that there were no ways to usefully use that password remotely. I am in that same position.

And I'm not in a unique position. Anyone out there with a plain old netgear/linksys/whatever NAT router will be just as safe as me (unless they've intentionally punched holes in it).

Re:Holy Ratshit, Batman!

[radish]

No, that's not what I'm saying. It's more like saying I'm not really worried about giving you the combination to my safe, because the 30ft high walls, armed guards and lava-filled moat will keep you out of the building it's in. And besides, if I get any hint you're even looking at my castle, I can just change the combination.

where do I find the hashes on my filesystem?

[Anonymous Coward]

Where on my filesystem do I find the hashes to paste into this program? Are they in the registry?

DNS Entries

[nuxx]

I think it'd be interesting to see this available via a DNS request, similar to how a number of black hole lists (RBLs) handle lookups.

Making software?

[Svartalf]

More like making adverts and misleading marketing. Their software's only so-so, better than their OSes, but definitely not great as many make it out to be.

Re:Making software?

[gargonia]

Yeah, I agree. Their software's not so wonderful, but it's a hell of a lot better than their OSes. Maybe if they'd stop trying to screw around in areas where they're not proficient they'd improve their software design.

Microsoftie says use passphrases

[aardwolf204]

There is an interesting entry in Robert Hensing's Incident Response blog about using passphrases to avoid using the NTLM hash. He is a microsoftie but what he says makes sense. I've since switched to using passphrases over 14 characters and so far have not be able to crack them with rainbow tables.

if your interested in a rainbow table demo one can be found here

MD5 SHA

[Dracolytch]

Oddly enough, I was going to start a similar project for SHA and MD5 hashes. Sure, the DB would be huge... But huge is easily dealt with. At 4 gigabytes per DVD-R (I know, I'm such a n00b, haven't gone dual-layer yet), .zip allowing compression to 2/3rds of disk space, that's about 64 million passwords per DVD.

One DVD could easily handle:
Every Zip
Every 7-digit phone number
Every word in the dictionary (Upper, lower, and Capitalized)

Move up to a 2 disc set and get:
Every date

With a little work it'd probably be possible to do names as well.

If you really want to brute force it:
Every possible password 8 characters or less could fit on a petabyte of storage. Expensive for your average geek, but how much do you want to bet that there's some government agency that did it on a lark?

~D

Re:Please explain

[Anonymous Coward]

it would be better to have the databases by hash rather then by password.

ie:
passwords with hashs starting with 0x00
passwords with hashs starting with 0x01
etc...

that way you don't have to ask all the databases the same question till you find an answer, you start off going to a database that will have your answer.

Terror bite worms?

[Anonymous Coward]

My God! I'm voting Bush.

One of us is missing something. I think it is you.

[John Harrison]

My understanding of the article is that "fiqojeio" would be in the DB and therefore is instantly crackable.

The point of the article isn't that "fiqojeio" is better or worse than "foo7bar+". It is that LM hashing method is weak and should not be used.

Re:Please explain

[Not_Wiggins]

That would be the best way to organize it once it is generated, but would also require the most interaction between "hackers."

I guess I was just thinking that someone could (as the people in the article did) just select some subset of passwords, generate all the hashes associated with those passwords, and publish it as a searchable database.

You know, Joe would generate hashes for all numbers, Sally would generate hashes for all letters and combinations with the number "1", etc.
Distributed that way, it would take not to long to generate all the hashes in parallel... and have searchably small databases.

Of course, then you'd have to search the search databases. 8)

But, once you have all the combinations generated by all these seperate sources, then it would make sense to combine and redistribute based on some other easy-to-identify characteristic (like the beginning of the hash-that-is-to-be-cracked).

I wonder if something like this would *never* gain any traction because, honestly, the people hosting these sorts of sites would also make themselves vulnerable. Just like that fictitious circuit from the movie "Sneakers:" "No more secrets."

That is NOT "reversing a hash" (-1, Misinformed)

[sczimme]

That is untrue. Any hash can be reversed in the sense that you can generate an input that will result in a specific output.

That is NOT reversing the hash: this should be painfully bloody obvious since the process you describe runs the same hash in the same manner.

Reversing a hash - meaning you start w/ the hash and work backwards to recreate the original data - is impossible. Bits are lost during the hash process, and there is no data in the hash that will allow those bits to be reconstructed. Read _Applied_Cryptography_ by Bruce Schneier, or at least read any of the many crypto/hash FAQs available on the web. NIST has some good papers available.

Re:Disable LM Hash--Macs, too

[Anonymous Coward]

This might only apply to Active Directory, but I'm seeing this with not only 95/98, but with any Mac OS prior to 10.2.6, including OS 9. No LM Hash, no authentication. Thursby's ADmit Mac seems to be the simplest solution, though I'm more than willing to hear others.

Re:Non sequitur? I think you mean...

[operagost]

I think he meant "ten years ago."

In other news

[psbrogna]

While it's fun to accuse MS, Moore's Law (and whatever corollary applies to storage) has caught up to encryption. I believe Dictionary Attacks and ever increasing speed/storage have rendered passwords as we know them as obsolete. Other than biometrics, anybody have any ideas? (Given of course that the average user can't remember a 6 digit voicemail password over a long weekend)

-1, Misinformative

[Henry V .009]

Bits don't have to be lost for a hash. Usually they are, but not always. Bits are lost because hash functions are normally designed to take an any length string and return a fixed length string. This is not always the case, however. With the LM hash specifically, the maximum input is 15 characters. While I do not know the precise algorithm used with LM, there is no reason that data must be lost by it.

Here's how

[Foolhardy]

In the local Security Policy->Security Options, you want to change "Network security: Lan Manager authentication level" to at least "Send NTLM response only". Or the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa\LmCompatibilityLevel to at least 2.

See this page for this and related policies.
This for an overview of LM, NTLM and NTLMv2.
And here to see how to prevent storage of LM hashes.

It doesn't matter. Really.

[juan large moose]

The LM and NTLM hashes are password equivalent.

If you have the LM Hash, and the server accepts LM Authentication, you don't need the password. At all.

Likewise, if you have the NTLM Hash, and the server accepts NTLM, NTLMv2, or LMv2 authentication, then you don't need the password.

The hashes are password equivalent.

I've written it all up in my online book (slashdot review), but...

Basically, the hashes are generated with no salt...nothing to obfuscate them. The algorithm used to log in is challenge/response:

• The server sends a random 8-byte string (the "challenge").
• Both client and server encrypt the challenge using the LM and/or NTLM Hash, not the password.
• The client sends its result (the "response") back to the server.
• The server compares results. If they match, the server grants access.

So... The hash is not exposed on the wire. It has to be reversed from the challenge and response. That's possible (and fairly easy with LM Auth), but it's got little to do with the password/LM Hash database.

The only way to use the LM Hash database to reverse the challenge/response is to use it as a hash dictionary.

Chris -)-----

Re:What is an LM hash?

[AndroidCat]

Was the OS/2 Lan Manager method much different from the Win95 Lan Manager hashing method? There might still be a few OS/2 systems out there ready to be pwn3d!

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.

Re:How to NOT store LM Hash

[juan large moose]

This is a very good point.

The LM and NTLM hashes are what really need to be protected. They are (as I keep saying...sorry I'm on a rant) password equivalent. Once someone has the hash the password itself is of minimal additional value.

Note that it is fairly easy to discover the LM Hash given an LM challenge/response pair. That's why the LM challenge/response should not be allowed on the wire.

It's also possible to reverse the hash from the NTLM, LMv2, and NTLMv2 challenge/response protocols, but it gets progressively harder as the algorithms improve.

It's all documented.

Chris -)-----

Re:Please explain

[AndroidCat]

Just take advantage of all those infected boxes with Swen, Sasser, MyDoom, etc, and build a large distributed net to fill the db. :)

Re:What is an LM hash?

[juan large moose]

They improved on it a while ago (NTLMv2) but still transmit the LM hash by default in all authentication - basically rendering the security of NTLMv2 completely useless.

The hashes are never transmitted on the wire during authentication. The mechanism is challenge/response, and the hashes are used by both the client and the server to encrypt the same random string. The server compares the results in order to determine whether or not the client knows the hash.

There are two hashes used: LM and NTLM. The LM Hash is used with LM Challenge/Response, and the NTLM Hash (which is the MD4() of the raw Unicode password string) is used for NTLM, NTLMv2, and LMv2 Challenge/Response. Two hashes, four mechanisms.

...then, of course, there's Kerberos.

The things that people keep missing in this discussion are:

• The hash is somewhat protected. You'd need to reverse the hash from the challenge/response or have direct access to the password files on the client or server in order to obtain the hash.
• Once you have the hash, you don't need the original password. The password is only used to generate the hash. All of the authentication steps are done using the hash, not the password.

It is possible to reverse the hash given the challenge and response. The LM Hash is much easier to reverse than the NTLM Hash, but the only way that this database will help is as a LM Hash dictionary.

Chris -)-----

Re:What is an LM hash?

[juan large moose]

LM = Lan Manager, the Windows 95 way of handling network passwords.

LAN Manager was more than just the password system, and it dates back well before W95.

hash = a way of storing passwords without leaving the password on the disk. You encrypt the password into a hash code and store that instead. You can't unencrypt it to derive the password but you can check a password guess by encrypting the guess the same way. If the guess hash == the password hash, you get in.

Yes, a good explanation, except... Unix systems generally add a bit of "Salt" to the hash so that the hash itself is not password equivalent. I have to be honest and state that I'm not sure exactly how that works. I'll have to do some reading in Schneier tonight. :)

The best part is, you don't have to keep the hash code a secret, because it's not the hard part. You're not asked to provide the hash value; you're asked to provide something that hashes to the value. So you can store it on the disk and even send it out over the LAN where it can be sniffed.

Nope. This may be true if salt is used, but there is no salt used when creating the LM or NTLM hashes. That, combined with the mechanism used for network authentication, result in this oft-forgotten fact: Windows LM and NTLM Hashes are password equivalent. They must be protected because, basically, they are the passwords!

That's very convenient: you can cache the hash code on every computer without having to trouble the central server to do the work. You don't want to send the password over the network (where it could be sniffed); nor is sending the hash code to the server for verification (because that could be spoofed). You distribute the hash to each computer, then let it decide if the password guess is correct. The password never goes across the network.

Ouch...no. That works for public key cryptography but you're describing a symmetric key system. Password hashes must be protected, even those with salt. That's why the password hashes on Unix systems are stored in the shadow files instead of the passwd file.

I've already described challenge/response in other posts on this topic. I'm in major fud-fight mode here. Read the docs: http://ubiqx.org/cifs/SMB.html#SMB.8.

Chris -)-----

Re:What is an LM hash?

[juan large moose]

Passwords longer than 14 bytes (OEM Charset) are truncated to form the LM Hash. The LM Hash may still be stored, it's just that you don't gain anything by having a password longer than 14 bytes.

If you disable LM Hashes altogether (as explained elsewhere in the comments) then you only have to worry about protecting the (stronger) NTLM Hash.

The NTLM hash is the MD4() of the full mixed case password in Unicode (UCS-2LE) password string.

Now available with contrast

[Anonymous Coward]

http://shit.slashdot.org/article.pl?sid=04/11/02/1 523212

Rainbow Tables , Make your own!

[OneArmedMan]

A buddy of mine works in Network Security, so for something to do and cause it would help him with his job we made our own rainbow tables. The time it took and disk space is roughly as follows.

5 average pc's ( all about 2000Mhz or so ) took about 30 days, and generated about 18Gb or tables.

Now these tables give us about 95%+ hit rate on any LM Hash we , erm "acquire"

The tables contain all hashes upto 14 Chars length using all letters all numbers and some symbols.

Just about the only hashes these tables wont hit are the machine generated ones.

I guess the point is turn *OFF* LM hashes at all cost, and if you absolutely "must" use them, make sure you kept them secure!

oh and a side note, if you are interested in cracking / brute forcing LM hashes, make sure to run them thru a copy of L0pht Crack or some such to get all the Blank, Pass==Name, Pass==Name-reversed hashes out of the way first.

Re:Rainbow Tables , Make your own!

[complete loony]

The only way to prevent these kinds of dictionary attacks with ANY password hashing method (SHA-1, MD5 etc), since the number of all possible 14 character passwords is limited, is to have some large unknown salt value. This then forces the hacker to reproduce the dictionary for all salt values.

Re:Rainbow Tables , Make your own!

[Vudu Child]

While that is true, there are significant design faults with LANMAN hashes that make the task much easier.

First all LANMAN passwords are not case sensitive.

Second the hash is made in two 7 character chunks which makes the search space much smaller.

Re:What is an LM hash?

[jfengel]

Thanks for the corrections. I actually should have waited for somebody who knew the Windows details; I was answering based on what I knew at the time. I'm not actually familiar with the details of the Windows challenge/response schemes.

I note, however, that early Unices didn't have a shadow password file; they really did keep the hashed passwords right out there in the open. Linux even supports this today.

Re:That is NOT "reversing a hash" (-1, Misinformed

[YetAnotherDave]

it isn't really a reversal, but you don't care, because it's the same result.

you pass in a hash, and it gives you a password that will result in that hash. There may be several passwords that could give you that hash, but you don't care, because you only need one.

Re:It doesn't matter. Really.

[theLOUDroom]

The only way to use the LM Hash database to reverse the challenge/response is to use it as a hash dictionary.

The real point is that if I can get access to your hard disk, I can grab all your password hashes.

This database make it trivial to then convert all those pasword hases back into passwords, pretty much instantly.

Re:That is NOT "reversing a hash" (-1, Misinformed

[Anonymous Coward]

You must have a proof that P!=NP if you can say impossible. Claim your prize It has been shown that unless we have P=NP => no pseudo-randomness => one-way hash functions do not exist, then it will indeed be possible.

Re:That is NOT "reversing a hash" (-1, Misinformed

[ajs]

Reversing a hash - meaning you start w/ the hash and work backwards to recreate the original data - is impossible

Not at all.

Bits are lost during the hash process, and there is no data in the hash that will allow those bits to be reconstructed.

Again, not true.

You would be correct if you had given the definitions and worked backward:

A hash is a set A of information which represents some n other sets of information, where n is greater than 0. Your statement fails for many reasons, but chief among them is the fact that no information need be lost in hashing an input (see below).

To "hash" an input requires a function f which, when passed an input B will always produce the output A. What people miss in looking at this is that A is not (necessarily) the unique result of "hashing" B with f, so reversing f (which is computationally hard, if f is a "good" or "strong" hashing function) is going to produce B along with zero or more (possibly infinite) other possible inputs. This is what it means to "reverse" a hash.

Let's take two examples (both of which are terrible hashing functions) to illustrate:

The "input as output" hash (f(x) = x) produces its input as its output. This hashing function is easy to reverse and always has exactly one output that maps to every input.

The "first letter" hash (f(x) = first_letter_of(x)) is a very different case. In this hash, we reliably produce a fixed-size output (a desirable trait in a hashing function). However, that means that an infinite number of inputs map to the output "a", and so on. However, if your inputs are restricted (e.g. they must be 2 or less letters), then the output is also restricted and it is quite reasonable to produce the inputs for any given output (e.g. for an output "a", the inputs "aa", "ab", "ac", etc.)

These are very bad hashes for different reasons depending on what application you have in mind. For example, for storage (e.g. indexing "buckets" in a hash table) the second function produces results which cluster too many inputs into the same buckets (e.g. "s" will be a very popular bucket, while "x" will not). For cryptography it is bad for the above reason, but also because it is computationally trivial to produce the list of inputs without brute force testing of the entire domain of inputs, or even a reasonably large subset of them.

If your hashing function is based on some complex mathematical problem, though, you might come very close to having an "unreversable" hash, but even the best hashes are in fact reversable. As with cryptography (and hashing is the fraternal twin of cryptography), absolute statements about hashing should be avoided at all costs unless you have a proof in hand.