Talk:LM hash

message: Shouldn't this page have a note saying how to disable the use of LM hashes?
--Wayne
: (At least) an external link would be worthwhile; does Microsoft describe how to do this in any of their support pages? — Matt 18:49, 2 Nov 2004 (UTC)
replies: text: Added.  --Hawke666 22:45, 2 Nov 2004 (UTC)
thread_title:  Disabling LM hashes 

message: The number of combinations seems incorrect. Usually the formula is (number of valid characters)^(length of password), or for a 7-character password using upper-case letter and numbers only, 36^7. 2^36 is far too small, unless there's a bug in LM Hash that I don't understand. 
: 24.81.71.14 
: I get log2(367) = 36.189475... (so 236 is about right.) I'm not sure about 284 for mixed case and numbers, though. I get (26 + 26 + 10)7 = 241.68. — Matt 19:21, 2 Nov 2004 (UTC)
replies: text:  For the record, 84 \approx \log_2\left(\left(26+26+10\right)^{14}\right). That’s not quite exact, but close enough. —xyzzyn 14:40, 14 June 2006 (UTC)
thread_title:  fact check request (moved from main article) 

message: Isn't that a contradiction? How could the hash generating function ever be reached with a >= 15 character password if the second quote is true? -- Aeluwas (talk) 19:34, 20 June 2009 (UTC)
replies: text: If you enter a 14-character password, Windows NT will store LM and NTLM hashes.  If you enter 15 characters, NT will store no LM hash and an NTLM hash. --John Moser (talk) 15:26, 28 October 2016 (UTC)
thread_title:  Contradiction in the article? 

message: "These values are used to create two DES keys, one from each 7-byte half, by converting the seven bytes into a bit stream, and inserting a zero bit after every seven bits. This generates the 64 bits needed for the DES key."
DES encryption standard using de facto 56-bit key, rest 8 bits are a parity-bits, so it's wrong to say what I highlighted above.
DES key:
???????P ???????P ???????P ???????P ???????P ???????P ???????P ???????P
Legend:
? - some bit
P - parity bit from last 7 bits
Parity-bits must be evaluated! Can't be just set to zero.  —Preceding unsigned comment added by 83.18.27.218 (talk) 07:30, 8 August 2009 (UTC)
thread_title:  Wrong understanding of DES encryption 

message: I'm surprised to see no mention of how much it facilitates dictionary attacks! While all the existing remarks about attacks are correct, they omit the most devastating attack against a very common case. The attacks described in the article totally kill LM Hash with modern computing resources, but the attack I am about to discuss usually killed it with the sort of desktop computing resources that were available even in the late 1980s, when rainbow tables were a pipe dream.
Consider passwords that are dictionary words, weakly perturbed dictionary words, or have some other similar sort of structure; and that are slightly longer than 7 characters. (Such passwords are very common in practice, in fact probably the most common type of password that is not totally trivial to crack.) The attacker can brute force the second half of the password in N^{L - 7} trials where N is the size of the symbol set and L is the full length of the password. For example, if a password is assumed to be composed of a random collection of printable characters then N = 96, and for L = 10 this yields 96^{10 - 7} = 884,736 trials, which even in the late 1980s was trivial to crack on a home PC -- say about 2 hours on a 4 MHz machine. If we assume the tail of the password is likely restricted to either single case alphabetic (one or the other case) or numerics, then with about the same effort we can hit L = 11 ( 26^{11 - 7} + 26^{11 - 7} + 10^{11 - 7} = 923,952.)
Here's the kicker: most passwords (except truly random ones) have some sort of structure which means that those last L - 7 characters will leak information about the first 7 once they are revealed (and of course it immediately reveals the length.) For example, "970" looks like it would fit very nicely with MM/DD/1970 or MM-DD-1970 (or DD/MM/1970 or DD-MM-1970) and you can confirm or disprove that hypothesis in just 1,172 trials taking just a few seconds even way back then. Thus under LM Hash, passwords with slightly more than 7 characters are actually weaker than ones with exactly 7!! As the password gets longer, cracking the tail gets harder but the attacker gets more information to help attack the head. Depending on the power of the attacker's computing resources the "sweet spot" probably falls somewhere between L = 10 and L = 12, where password strength is minimised. That happens also to be about the maximum length that people used to use for critical admin passwords, thinking such a length would be highly secure ... Needless to say, this is a highly undesirable property!
Now, all of the foregoing can't be published, due to the original research rule. However, I didn't invent it; I'm sure if we look hard enough, we'll find an old description of this technique. -- 202.63.39.58 (talk) 12:30, 18 August 2009 (UTC)
replies: text: Is L0phtCrack open source or reviewed somewhere perhaps? Socrates2008 (Talk) 12:51, 18 August 2009 (UTC)
thread_title:  It's even weaker than that! 

message: It would help a lot to add a timeline to the article.  When was this scheme cooked up (vs the use in Unix of salts and iteration counts in 1974, as I recall), and when was it first deployed?  When was it in peak usage?  When did it start being exploited frequently?  ★NealMcB★ (talk) 15:52, 18 February 2011 (UTC)
thread_title:  Timeline? 

message: This page and NT LAN Manager have seemingly a lot of the same information and neither of them make clear if LM Has and NTLM Hashes are the same.
Is NTLMv1=LM Hash?
is NTLMv2=????
The two pages should have consistent naming at least.  — Preceding unsigned comment added by Jwilleke (talk • contribs) 14:07, 12 June 2016 (UTC)
replies: text: There's an old merge proposal over at LAN Manager, but there's no result yet. -- Evilninja (talk) 02:39, 13 June 2016 (UTC)
thread_title:  NTLM NTLMv1 NTLMv2 and LM Hash 

message: Is it worth noting that historical security advice against LM hash is ineffective?  MSDN has the following two statements in the same article:
* "Note that due to the way LM hashes are created, putting a symbol as the only entropy in the eighth position of an eight character password only has a small impact on password complexity. For maximum entropy and complexity, non-alphanumeric characters need to be present throughout the password."
* "A strong password is a password that is at least eight characters long and uses characters from three of the five following groups:"
As near as I can tell, the eight-character password advice originated due to the flaw in LM hash; this is, to my understanding, common knowledge in the IT Security field.  Correct me if I'm wrong (in which case this is OR).  That, plus the above quotes from the same article, produces a notable incidence of ineffective security advice becoming an accepted tenet in the field:  An eight-character password isn't any more secure than a seven-character password.
At the time, rainbow tables were a novel idea; the original advice for eight character passwords cited that LM hash would create a known value for the second-half hash if a password was 7 characters.  Extending this, the LM hash will create one of 67 known values for the second-half if you use an 8-character password.  Rainbow tables are the extension of this property to large dictionaries.  The problem with the original advice is that 67 known values would be not only human-memorable, but essentially a few bytes in a text file rather than a 388 megabyte LM hash rainbow table (computer memory was limited at the time, and 388MB was even a considerable amount of storage space--Windows 98 installed in 200MB--and besides, rainbow tables showed up in 2003).  This means all 8-character passwords are 7-character passwords in LM hash, if using a brute-force or dictionary attack rather than a rainbow table.
In other words:  the advice to use 8-character passwords was wrong when it was first published.  Whether this is useful for the article or not depends on whether the above information is considered common-knowledge in the professional field or research-grade analysis and thus original research.  Someone else can decide. --John Moser (talk) 15:41, 28 October 2016 (UTC)
thread_title:  Ineffective security advice