Talk:NTLM

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Microsoft Windows: Computing Mid‑importance This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows articles Mid This article has been rated as Mid-importance on the project's importance scale. This article is supported by WikiProject Computing (assessed as Mid-importance). Networking task force (assessed as Mid-importance). This article is supported by WikiProject Software (assessed as Mid-importance).

Computer Security: Computing Mid‑importance

This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer SecurityWikipedia:WikiProject Computer SecurityTemplate:WikiProject Computer SecurityComputer Security articles Mid This article has been rated as Mid-importance on the project's importance scale. This article is supported by WikiProject Computing (assessed as Mid-importance). Things you can help WikiProject Computer Security with: AAlertBot. Please allow some days for processing. More information... Answer question about Same-origin_policy Review importance and quality of existing articles Identify categories related to Computer Security Tag related articles Identify articles for creation (see also: Article requests) Identify articles for improvement Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc. Find editors who have shown interest in this subject and ask them to take a look here.

The statement "NTLM remains vulnerable to the pass the hash attack, which is a variant on the reflection attack which was addressed by Microsoft security update MS08-068." is complete nonsense. Pass-the-hash refers to using the raw password hashes in memory of a machine to establish new connections. That has absolutely nothing to do with a reflection attack which attacks a client trying to connect to a rogue server by using client's own hashes to connect back to the client over a new connection. The whole vulnerabilities / weakness section is also a little dubious for a number of reasons. One is that references to "cracking" do not explain that an attacker must first break into a machine and steal said hashes. Without that explaination, the reader might get the impression that the non-raw hashes factored with client challenges are being cracked. That is not the case. Similarly, a pass-the-hash attack also must first break into a machine to steal the raw password hashes. There is no protection against such an attack. All auth protocols are vulnerable to such an attack. Kerberos tickets can be used in exactly the same way. And to get password hashes that are actually useful, an attacker would have to break into a domain controller with system privs. That whole section is disingenuous at the least. — Preceding unsigned comment added by Miallen (talk • contribs) 21:07, 16 July 2019 (UTC)[reply]

I'm happy this was broken out from IWA. Thanks. Ozga 02:21, 27 September 2006 (UTC)[reply]

Can someone define what NTLM stands for? Is it an acronym? "NT" Lan Manager?

I think so. But see http://support.microsoft.com/?kbid=239869, where Microsoft calls it Windows NT challenge/response. Ozga 13:23, 5 October 2006 (UTC)[reply]

<Snipped event log entry>

Jeffrey Walton

Noloader (talk) 19:27, 15 August 2010 (UTC)[reply]

I get a feeling that the sections that describe the protocol are based on the old reverse engineered understanding of how NTLM works. These days - when the specification for the protocol has been fully disclosed by Microsoft - the reader is probably better off reading Microsoft's official documentation of NTLM (see official documentation) than this Wikipedia article.

— comment added by TeddyCanoby (talk • contribs) 17:26, 02 May 2010 (UTC)[reply]

Agreed. First attempt at resolving complete. Protocol details have not been scrutinized. On the bad side, I needed to cite primary sources for some details.

Jeffrey Walton Noloader (talk) 19:52, 15 August 2010 (UTC)[reply]

The two sentences, "Both MS-CHAP v1 and v2 have been cryptanalyzed. However, they continue to be in widespread use," would seem to imply that being crytanalyzed is somehow a bad thing. In this case, I believe what was meant was something more along the lines of, "Cryptanalysis of MS-CHAP v1 and v2 have shown the algorithm is not cryptographically secure, but they nevertheless continue to see widespread use." Any objections to that change? Jouster  (whisper) 20:56, 7 June 2007 (UTC)[reply]

There's a little confusion in the introductory wording over version numbers. "NT LM 0.12" is the version number of the SMB (aka CIFS) protocol, not the version number of NTLM. The SMB protocol negotiation decides what version of SMB will subsequently be spoken, not (directly) what authentication mechanisms will be employed.

Within NT LM 0.12 (which is the version of the protocol introduced with Windows NT back in 1993 or thereabouts) there are then mechanisms for determining the authentication protocols: plaintext password, LM, NTLM, Kerberos, NTLMv2, etc. Some of these auth protocols are also applicable to older versions of SMB, of course.

dave

Please suggest corrections.

This page doesn't really have much structure and begins far too technically. Although it has headings, the use of language doesn't really communicate the issue concisely.

210.211.170.42 (talk) 09:49, 27 November 2007 (UTC)[reply]

Agreed. First attempt at resolving complete. Protocol details have not been scrutinized. On the bad side, I needed to cite primary sources for some details.

Jeffrey Walton Noloader (talk) 19:53, 15 August 2010 (UTC)[reply]

There is no note but you get referred there (MS-CAHPv2 would have less weaknesses then MS-CHAPv1) —Preceding unsigned comment added by 82.92.18.24 (talk) 20:13, 18 February 2008 (UTC)[reply]

Microsoft has fully documented the protocol since 2007.

In the "NTLMv2-Session" section it the article says:

The NTLMv2 Session protocol is entirely different, being very similar to MS-CHAPv2. It is described by Eric Glass' ntlm page.

Why is it 'described by Eric Glass' ntlm page' when there is now an official documentation ?

Some of the NTLM implementations that exist out there (e.g. Samba) were made before MS's disclosure, i.e. they were made by reverse engineering the protocol. This is of course error prone. Such implementations could benefit a lot from being re-made now that it has been fully documented by MS. This has unfortunately not happened.

It is not very clear from the text so I'll spill the beans here:

All Windows Communication Protocols (NTLM being one of them) are documented here:

http://msdn.microsoft.com/en-us/library/cc216513(PROT.10).aspx

The specifications relating to NTLM are:

MS-NLMP: Main document describing NTLM v1, NTLM v2. etc.
http://msdn.microsoft.com/en-us/library/cc236621(PROT.10).aspx

MS-NTHT: NTLM over HTTP protocol
http://msdn.microsoft.com/en-us/library/cc237488(PROT.10).aspx

MS-NNTP: Specifies the use of NTLM authentication by NNTP (Network News Transfer Protocol)
http://msdn.microsoft.com/en-us/library/cc236774(PROT.10).aspx

MS-POP3: NTLM for use with POP3
http://msdn.microsoft.com/en-us/library/cc239183(PROT.10).aspx

MS-SMTP: NTLM for use with SMTP
http://msdn.microsoft.com/en-us/library/cc246807(PROT.10).aspx

I do not understand why the article still refers to the documentation from those who reverse engineered the protocol as if it is THE documentation. These guys did a fantastic job but these days it is history. —Preceding unsigned comment added by TeddyCanoby (talk • contribs) 22:40, 18 April 2009 (UTC)[reply]

Agreed. First attempt at resolving complete. Protocol details have not been scrutinized. On the bad side, I needed to cite primary sources for some details.

Jeffrey Walton Noloader (talk) 19:54, 15 August 2010 (UTC)[reply]

Just out of curiosity, if anyone ever come across the story behind selecting the above string, it would be worth including it in the article. Such facts do make an article interesting, and more likely one will remember the content of the article. Just a thought.

Quote

The LM hash is constructed from the uppercase, ASCII version of the user’s password. The password is truncated/NULL padded to 14 ASCII characters1 , and split into two 7 byte halves. Each half is used as a key to encrypt the constant string “KGS!%@$%”.

End quote

www.samba.org/samba/news/articles/abartlet_thesis.pdf

The section on NTLMv2 contradicts itself, leaving me unclear on how it really works. First it says "NTLM2 sends two 16-byte responses to an 8-byte server challenge." Later, it refers to these two responses as "the shorter response" and a variable-length "second response". That whole section is confusing, and inconsistencies like this certainly don't help. Could someone who is certain of how NTLMv2 actually works please revise that section? --Jeremy Reeder, CJS, CPS (talk) 21:25, 6 August 2009 (UTC)[reply]

I believe there is a lot of mistaken information in the NTLMv2 section of the article right now, and there are certainly some things that aren't clear. The pseudo-code doesn't even seem to match the text. The following is my understanding of how NTLMv2 works:

In NTLMv2, the client requests a login challenge from the server. That challenge request includes a username. The server sends the client a random 16-byte authenticator challenge. From that challenge, the client derives an 8-byte challenge as follows: It creates a random 16-byte peer authenticator challenge, appends the authenticator challenge and the client's username to it, hashes the result with SHA-1, and takes the first eight bytes of that hash. It then encrypts the 8-byte challenge using the 16-byte MD4 hash of the user's password as the encryption key. Then the client responds to the server with the peer authenticator challenge and with this 24-byte encrypted value.

In order to verify the client's response, the server generates the 8-byte challenge in the same way that the client did except that it uses the peer authenticator challenge provided by the client rather than generating a random one. The server then decrypts the 24-byte response from the client using the MD4 hash of the user's password as the decryption key, and it compares the decrypted result to the now-known 8-byte challenge. If the two match, then the server knows that the client knows the MD4 hash of the user's correct password. In that case, the server considers the client's identity to have been verified.

But the client is not yet sure of the server's identity, so the server server must now send a mutual authenticator response. To do this, it first concatenates a hash of the MD4 password hash (yes, a hash of a hash), the 24-byte client-response, and the string "Magic server to client constant". Next, it hashes the result with SHA-1 and appends to that hash the 8-byte challenge and the string "Pad to make it do more than one iteration". Finally, it hashes that result with SHA-1.

The client generates the mutual authenticator response in the same way and verifies that it matches the response received from the server. If it does, then the client knows that the server knows the MD4 hash of the user's password. In that case, the client now considers the server's identity to be verified. --Jeremy Reeder, CJS, CPS (talk) 14:52, 7 August 2009 (UTC)[reply]

I must have been mistaken. This is how MS-CHAPv2 works, not NTLMv2. According to this article, NTLMv2-Session (not NTLMv2) is similar to MS-CHAPv2, while NTLMv2 is "a cryptographically strengthened replacement for NTLMv1". So I'm not suggesting that my description above be put into the NTLMv2 section of the article, but I still say that it's unclear how it works, and that the description seems to be inconsistent with itself. I'd appreciate it if someone could clear this up. --Jeremy Reeder, CJS, CPS (talk) 19:02, 12 August 2009 (UTC)[reply]

I have php code for forcing NTLM, with the sends and responses, and the instructions on how to set up all the common browsers for NTLM. If you would like this included then please send me a message. Regards, Dean Dean (talk) 15:28, 28 April 2010 (UTC)[reply]

Probably not appropriate for the NTLM article. Perhaps a programming site, such as CodeProject.com or CodeGuru.com, would be more appropriate.

Jeff Noloader (talk) 20:08, 14 August 2010 (UTC)[reply]

Removed from the article (was the second sentence of the article). I understand the motivation (and the need for a citation), but its not appropriate in the context/flow.

<quote>

Jeff Noloader (talk) 19:27, 14 August 2010 (UTC)[reply]

While the *official* documentation is probably of great value to a programmer, it is not really encyclopedic. At best, it might be appropriate for See Also or External Links (and its already in external links). Its also link heavy.

<quote>Microsoft has fully documented the protocol since 2007. ^{[citation needed]}

All Windows Communication Protocols (NTLM being one of them) are documented here:

http://msdn.microsoft.com/en-us/library/cc216513(PROT.10).aspx

The specifications relating to NTLM are:

MS-NLMP: Main document describing NTLM v1, NTLM v2. etc.
http://msdn.microsoft.com/en-us/library/cc236621(PROT.10).aspx

MS-NTHT: NTLM over HTTP protocol
http://msdn.microsoft.com/en-us/library/cc237488(PROT.10).aspx

MS-NNTP: Specifies the use of NTLM authentication by NNTP (Network News Transfer Protocol)
http://msdn.microsoft.com/en-us/library/cc236774(PROT.10).aspx

MS-POP3: NTLM for use with POP3
http://msdn.microsoft.com/en-us/library/cc239183(PROT.10).aspx

MS-SMTP: NTLM for use with SMTP
http://msdn.microsoft.com/en-us/library/cc246807(PROT.10).aspx </quote>

Jeff Noloader (talk) 20:04, 14 August 2010 (UTC)[reply]

Awkward, fishy: NTLM and MS-CHAP (to paraphrase) are cryptographically identical or cryptographically equivalnet. The paragraph then makes claims about MS-CHAP security (in a *NTLM* article). Is the reader supposed to make the leap, and apply the findings to NTLM?

<quote>Both MS-CHAP v1 and v2 have been analyzed; Bruce Schneier, Peiter "Mudge" Zatko and David Wagner, among other researchers, found weaknesses in both protocols.^[1] Still both protocols remain in widespread use.</quote>

Jeff Noloader (talk) 20:49, 14 August 2010 (UTC)[reply]

The crap below was gutted from The Protocol. The first sentence discusses the SAMBA team's RE efforts. The second sentence starts with a statement about MS-CHAP, makes an unsubstantiated MS-CHAP <-> NTLM equivalency claim, and refers to RFC's that are part of Microsoft PPP extensions.

Freetards (you know who I am talking to): tighten your shit up. This isn't a free software project where others are going to fix your bugs.

Jeffrey Walton Noloader (talk) 18:21, 15 August 2010 (UTC)[reply]

<quote>Before official documentation for NTLM was made available in 2007 ^{[citation needed]}, the protocol was analyzed by the Samba team using network traffic analysis. The cryptographic algorithms and calculations are identical to that of MS-CHAP ^{[citation needed]} and are documented in RFC 2433 and RFC 2759. ^[vague]</quote>

WTF???? Where do these terms come from? The crap below was gutted from The Protocol. Freetards (you know who I am talking to): tighten your shit up. This isn't a free software project where others are going to fix your bugs.

Since the freetards could not get the message names right, I have no faith in their ability to properly describe the protocol (worst: all they have to do is reference the specification, and the link is provided in the article).

Looking at Microsoft's specification, the message names are NEGOTIATE_MESSAGE, CHALLENGE_MESSAGE, and AUTHENTICATE_MESSAGE. See NTLM Messages at http://msdn.microsoft.com/en-us/library/cc236640%28v=PROT.10%29.aspx.

Jeffrey Walton Noloader (talk) 18:18, 15 August 2010 (UTC)[reply]

<quote> The protocol uses a

1. The client first sends a Type 1 message containing a set of flags of features supported or requested (such as encryption key sizes, request for mutual authentication, etc.) to the server.
2. The server responds with a Type 2 message containing a similar set of flags supported or required by the server (thus enabling an agreement on the authentication parameters between the server and the client) and, more importantly, a random challenge (8 bytes).
3. Finally, the client uses the challenge obtained from the Type 2 message and the user's credentials to calculate the response. The calculation methods differ based on the NTLM authentication parameters negotiated previously, but in general they apply MD4/MD5 hashing algorithms and DES encryption to compute the response. The client then sends the response to the server in a Type 3 message.

</quote>

I think that the way this protocol is now being described isn't correct. It is a compendium of facts which are obvious to a person intimately familiar with the protocol and of little value to anyone else. I think the descriptions that provide an understanding first, and details second, is better. Particularly since security algorithms are mathematics. The mathematics stands on its own, and is what it is. The explanation is what gives it meaning.

This looks like more freetard babble. (1) there are too many vague and uncited statements (2) What is the need for a statement such as, "Many implementations are by Microsoft". (3) In an article discussing a Microsoft authentication protocol, why is a freetard going off on a tangent claiming Samba, Cyrus SASL, Squid, etc are using reverse engineered implementations because they have not consulted Microsoft's published documentation. [sic] (4) Does the third statement even hold in 2010?

Spurious, superfluous, and now removed.

Jeffrey Walton Noloader (talk) 19:05, 15 August 2010 (UTC)[reply]

<quote> Many implementations are by Microsoft. In addition a large number of third-party software also implement NTLM. This includes many open source applications that run on non-Microsoft platforms, e.g. Linux/Unix, thereby allowing such applications to interoperate with Microsoft products such as Active Directory, Exchange Server (mail server), Internet Information Services (http server), etc.

Many non-Microsoft implementations were developed at a time when no official documentation was available from Microsoft, that is before 2007. Such implementations are based on reverse engineering. None of the major open source implementations of NTLM (Samba, Cyrus SASL, Squid, etc) seem^[who?] to have re-designed their software after the official documentation became available in 2007 but are indeed still based on a reverse engineered understanding of the protocol.^{[citation needed]} </quote>

Another section that looks like freetard babble. (I'm not opposed to discussing short-comings and vulnerabilities, but this looks like a cheap stab at Microsoft). You can take shots at Microsoft, but it has to be well written, cited, and discussed in a neutral point of view - get rid of the 'cheapness'. And get the fact right: its not a man-in-the middle - its a reflection attack by a passive adversary (ie, eavesdropper).

Freetards (you know who I am talking to): tighten your shit up. This isn't a free software project where others are going to fix your bugs.

Jeffrey Walton Noloader (talk) 19:34, 15 August 2010 (UTC)[reply]

<quote> NTLM is vulnerable to a credentials forwarding attack by a man-in-the-middle.^{[citation needed]} Some applications which use NTLM have protected themselves ^{[citation needed]}, but a more fundamental fix is needed.^{[citation needed]} </quote>

Thank you for lots of good cleanup on this article - It's great to have some more expertise around here. But please be civil and avoid ad hominem and personal attacks (

WP:GOODFAITH

. And note that somehow previously a helpful citation was removed, and at some point requests for "citation needed" were added for points which were addressed in the original citation. So what is quoted here is not the original.

I've added a Vulnerabilities section back and improved the text and citations. --NealMcB (talk) 04:20, 24 August 2010 (UTC)[reply]

Here it is, in all its glory. It appears to be programmer notes that were dropped in the wrong section.

Jeffrey Walton Noloader (talk) 20:22, 15 August 2010 (UTC)[reply]

<quote> Technically speaking {{offensive...}}, the computer will accept LM for inbound authentication but by default neither Windows Vista nor Windows Server 2008 store the LM hash. ^{[vague][citation needed]}. Therefore, there is no way for them to authenticate an inbound LM response - typical error message is System error 86 has occurred. The specified network password is not correct. Authentication behavior can be specified, starting with Windows NT 4.0 Service Pack 4, using the LMCompatibilityLevel registry setting, shown in Group Policy as Network Security:LAN Manager Authentication Level. The default value for LMCompatibilityLevel in Windows Vista, Windows 7 and Windows Server 2008 is 3, or Send NTLMv2 Response Only. ^[vague] </quote>

It should be said in the article that Opera is the only major Web browser that does not support NTLM authentication. For security reasons, I suppose. —Preceding unsigned comment added by 85.139.250.34 (talk) 11:02, 9 March 2011 (UTC)[reply]

What you say has nothing to do with the article, calling it a major browser so it must be cited because of security reasons, if browser compatibility should be added it should have a list of all browsers that support it or not... Look, even Microsoft says the suite isn't secure, if it continues widely implemented no one really cares about this stuff. --Rafaelluik (talk) 18:07, 9 August 2011 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified 4 external links on

• Added {{dead link}} tag to http://blogs.iss.net/archive/NTLMReflection.html
• Added archive https://web.archive.org/web/20100601113646/http://palisade.plynt.com/issues/2006Feb/rainbow-tables/ to http://palisade.plynt.com/issues/2006Feb/rainbow-tables/
• Added archive https://web.archive.org/web/20141006095627/http://www.aorato.com/blog/active-directory-vulnerability-disclosure-weak-encryption-enables-attacker-change-victims-password-without-logged/ to http://www.aorato.com/blog/active-directory-vulnerability-disclosure-weak-encryption-enables-attacker-change-victims-password-without-logged/
• Added archive https://web.archive.org/web/20070213065618/http://www.midgard-project.org/documentation/ntlm-single-sign-on/ to http://www.midgard-project.org/documentation/ntlm-single-sign-on/
• Added archive https://web.archive.org/web/20120220083823/https://www.objectif-securite.ch/en/products.php to http://www.objectif-securite.ch/en/products.php

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:35, 11 February 2018 (UTC)[reply]

"Whether these protocols are used or can be used on a system which is governed by Group Policy settings, for which different versions of Windows have different default settings." Whether these protocols are used what? Where's the predicate of this sentence? I honestly do not know. Is it just removing the word "which" that is called for? I sincerely don't know how to fix. IAmNitpicking (talk) 11:48, 7 February 2023 (UTC)[reply]