Slashdot Mirror
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."
I think someone is underestimating the /. effect.
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?
apterous.org
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.
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.
; EN-US;q299656
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
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....
"TV is great! Every New Year's I make a resolution to watch more TV." - Ann Coulter
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.
Dear Slashdot Readers,
Thank you for letting us know your passwords.
Regards,
The staff of beginningtoseethelight
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.
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
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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!!!
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:
; EN-US;q299656
http://support.microsoft.com/default.aspx?scid=KB
TODO: come up with a clever sig
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
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.
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.
This issue is a bit more complicated than you think.
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
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.
I want to drag this out as long as possible. Bring me my protractor.
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.
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:
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 -)-----