ในเครือข่ายWindows นั้น NT (New Technology) LAN Manager ( NTLM ) เป็นชุดโปรโตคอลความปลอดภัยของ Microsoft ที่ออกแบบมาเพื่อมอบการตรวจสอบสิทธิ์ ความสมบูรณ์ และการรักษาความลับให้กับผู้ใช้ ^{[ 1 ] [ 2 ] [ 3 ]} NTLM เป็นโปรโตคอลที่พัฒนาต่อจากโปรโตคอลการตรวจสอบสิทธิ์ใน Microsoft LAN Manager (LANMAN) ซึ่งเป็นผลิตภัณฑ์เก่าของ Microsoft ชุดโปรโตคอล NTLM ถูกนำไปใช้ในSecurity Support Providerซึ่งรวม โปรโตคอลการตรวจสอบสิทธิ์ LAN Manager , NTLMv1, NTLMv2 และโปรโตคอล NTLM2 Session ไว้ในแพ็กเกจเดียว การที่โปรโตคอลเหล่านี้ถูกใช้งานหรือสามารถใช้งานได้บนระบบนั้นขึ้นอยู่กับ การตั้งค่า Group Policyซึ่ง Windows เวอร์ชันต่างๆ จะมีการตั้งค่าเริ่มต้นที่แตกต่างกัน

รหัสผ่าน NTLM ถือว่าอ่อนแอเพราะสามารถถูกโจมตีแบบ Brute-forceได้ง่ายมากด้วยฮาร์ดแวร์สมัยใหม่^{[ 4 ]}

NTLM เป็นโปรโตคอลการตรวจสอบสิทธิ์แบบท้าทาย-ตอบสนองซึ่งใช้ข้อความสามข้อความในการตรวจสอบสิทธิ์ไคลเอ็นต์ในสภาพแวดล้อมแบบเชื่อมต่อ (แบบไม่เชื่อมต่อก็คล้ายกัน) และข้อความเพิ่มเติมข้อที่สี่หากต้องการความสมบูรณ์^{[ 5 ] [ 6 ] [ 7 ] [ 8 ]}

1. ขั้นแรก ไคลเอนต์จะสร้างเส้นทางเครือข่ายไปยังเซิร์ฟเวอร์และส่ง NEGOTIATE_MESSAGE เพื่อประกาศความสามารถของตน^{[ 9 ]}
2. ถัดไป เซิร์ฟเวอร์จะตอบกลับด้วย CHALLENGE_MESSAGE ซึ่งใช้ในการสร้างตัวตนของไคลเอนต์^{[ 10 ]}
3. สุดท้าย ลูกค้าจะตอบสนองต่อความท้าทายด้วย AUTHENTICATE_MESSAGE ^{[ 11 ]}

โปรโตคอล NTLM ใช้ค่ารหัสผ่านที่แฮชไว้หนึ่งค่าหรือทั้งสองค่า ซึ่งทั้งสองค่านี้จะถูกจัดเก็บไว้บนเซิร์ฟเวอร์ (หรือตัวควบคุมโดเมน) และเนื่องจากไม่มีการเติมเกลือ (salting) จึงเทียบเท่ากับรหัสผ่าน หมายความว่าหากคุณดึงค่าแฮชจากเซิร์ฟเวอร์ คุณสามารถตรวจสอบสิทธิ์ได้โดยไม่ต้องรู้รหัสผ่านจริง ค่าทั้งสองคือLM hash ( ฟังก์ชันที่ใช้ DESกับอักขระ 14 ตัวแรกของรหัสผ่านที่แปลงเป็นชุดอักขระ PC 8 บิตแบบดั้งเดิมสำหรับภาษา) และ NT hash ( MD4ของ รหัส ผ่าน Unicode UTF-16 แบบ little endian ) ค่าแฮชทั้งสองค่ามีขนาด 16 ไบต์ (128 บิต) ^{[ 12 ]}

โปรโตคอล NTLM ยังใช้ฟังก์ชันทาง เดียวสองฟังก์ชัน ขึ้นอยู่กับเวอร์ชัน NTLM; NT LanMan และ NTLM เวอร์ชัน 1 ใช้ฟังก์ชันทางเดียว LanMan ที่ใช้ DES (LMOWF) ในขณะที่ NTLMv2 ใช้ฟังก์ชันทางเดียว NT MD4 (NTOWF) ^{[ 12 ] [ 13 ]}

เซิร์ฟเวอร์ตรวจสอบความถูกต้องของไคลเอนต์โดยการส่งหมายเลขสุ่ม 8 ไบต์ ซึ่งเรียกว่า "คำท้า" ไคลเอนต์จะดำเนินการบางอย่างโดยใช้คำท้าและรหัสลับที่ใช้ร่วมกันระหว่างไคลเอนต์และเซิร์ฟเวอร์ โดยเฉพาะอย่างยิ่ง หนึ่งในสองค่าแฮชรหัสผ่านที่กล่าวถึงข้างต้น ไคลเอนต์จะส่งผลลัพธ์การคำนวณขนาด 24 ไบต์กลับมา ในความเป็นจริง ใน NTLMv1 การคำนวณมักจะใช้ทั้งสองค่าแฮช และผลลัพธ์ขนาด 24 ไบต์ทั้งสองจะถูกส่งกลับมา เซิร์ฟเวอร์ตรวจสอบว่าไคลเอนต์คำนวณผลลัพธ์ที่ถูกต้องหรือไม่ และจากนั้นจึงอนุมานได้ว่าไคลเอนต์มีรหัสลับ และด้วยเหตุนี้จึงยืนยันความถูกต้องของไคลเอนต์ได้

แฮชทั้งสองแบบสร้างค่าขนาด 16 ไบต์ จากนั้นเติมศูนย์ 5 ไบต์เพื่อให้ได้ 21 ไบต์ 21 ไบต์นี้จะถูกแบ่งออกเป็น 3 ส่วน ส่วนละ 7 ไบต์ (56 บิต) แต่ละส่วนของค่า 56 บิตนี้จะถูกใช้เป็นคีย์ในการ เข้ารหัส DES สำหรับ คำถามท้าทายขนาด 64 บิต การเข้ารหัสทั้งสามส่วนของคำถามท้าทายจะถูกนำมารวมกันเพื่อสร้างคำตอบขนาด 24 ไบต์ ทั้งคำตอบที่ใช้แฮช LM และแฮช NT จะถูกส่งกลับมา แต่สามารถกำหนดค่าได้

C = การท้าทายเซิร์ฟเวอร์ 8 ไบต์ แบบสุ่ม K1 | K2 | K3 = NTLM-Hash | 5-bytes-0 การตอบสนอง = DES(K1,C) | DES(K2,C) | ดีเอส(K3,C) 

NTLMv2 ซึ่งเปิดตัวในWindows NT 4.0 SP4 ^{[ 14 ]} (และได้รับการสนับสนุนโดยตรงใน Windows 2000) เป็นโปรโตคอลการตรวจสอบสิทธิ์แบบท้าทาย-ตอบสนอง มีจุดประสงค์เพื่อใช้แทน NTLMv1 ที่มีความแข็งแกร่งทางด้านการเข้ารหัส โดยเพิ่มความปลอดภัยของ NTLM ด้วยการเสริมความแข็งแกร่งของโปรโตคอลเพื่อป้องกันการโจมตีแบบปลอมแปลงหลายรูปแบบ และเพิ่มความสามารถให้เซิร์ฟเวอร์สามารถตรวจสอบสิทธิ์กับไคลเอนต์ได้^{[ 1 ] [ 15 ] [ 16 ]}

NTLMv2 ส่งการตอบกลับสองชุดไปยัง คำถามท้าทายจากเซิร์ฟเวอร์ขนาด 8 ไบต์การตอบกลับแต่ละชุดประกอบด้วย แฮช HMAC - MD5 ขนาด 16 ไบต์ ของคำถามท้าทายจากเซิร์ฟเวอร์คำถามท้าทายจากไคลเอ็นต์ ที่สร้างขึ้นแบบสุ่มทั้งหมด/บางส่วน และแฮช HMAC-MD5 ของรหัสผ่านของผู้ใช้และข้อมูลระบุตัวตนอื่นๆ การตอบกลับทั้งสองชุดแตกต่างกันในรูปแบบของคำถามท้าทายจากไคลเอ็นต์ การตอบกลับที่สั้นกว่าจะใช้ค่าสุ่มขนาด 8 ไบต์สำหรับคำถามท้าทายนี้ เพื่อตรวจสอบความถูกต้องของการตอบกลับ เซิร์ฟเวอร์ต้องได้รับคำถามท้าทายจากไคลเอ็นต์เป็นส่วนหนึ่งของการตอบกลับ สำหรับการตอบกลับที่สั้นกว่านี้ คำถามท้าทายจากไคลเอ็นต์ขนาด 8 ไบต์ที่ต่อท้ายการตอบกลับขนาด 16 ไบต์จะทำให้เกิดแพ็กเกจขนาด 24 ไบต์ ซึ่งสอดคล้องกับรูปแบบการตอบกลับขนาด 24 ไบต์ของโปรโตคอล NTLMv1 รุ่นก่อนหน้า ในเอกสารที่ไม่เป็นทางการบางฉบับ (เช่น DCE/RPC Over SMB, Leighton) การตอบกลับนี้เรียกว่า LMv2

การตอบสนองครั้งที่สองที่ส่งโดย NTLMv2 ใช้การท้าทายไคลเอ็นต์ที่มีความยาวแปรผันได้ ซึ่งประกอบด้วย (1) เวลาปัจจุบันใน รูปแบบ NT Time (2) ค่าสุ่ม 8 ไบต์ (CC2 ในช่องด้านล่าง) (3) ชื่อโดเมน และ (4) ข้อมูลรูปแบบมาตรฐานบางอย่าง การตอบสนองต้องมีสำเนาของการท้าทายไคลเอ็นต์นี้ ดังนั้นจึงมีความยาวแปรผันได้ ในเอกสารที่ไม่เป็นทางการ การตอบสนองนี้เรียกว่า NTv2

ทั้ง LMv2 และ NTv2 ใช้การแฮชข้อมูลการท้าทายจากไคลเอ็นต์และเซิร์ฟเวอร์ร่วมกับการแฮช NT ของรหัสผ่านของผู้ใช้และข้อมูลระบุตัวตนอื่นๆ สูตรที่แน่นอนคือ เริ่มต้นด้วยการแฮช NT ซึ่งจัดเก็บไว้ในSAMหรือ AD จากนั้นจึงทำการแฮชต่อโดยใช้HMAC - MD5กับชื่อผู้ใช้และชื่อโดเมน ในช่องด้านล่าง X หมายถึงเนื้อหาคงที่ของฟิลด์การจัดรูปแบบ

SC = การท้าทายเซิร์ฟเวอร์ 8 ไบต์ แบบสุ่ม CC = รหัสท้าทายไคลเอ็นต์ 8 ไบต์ แบบสุ่ม CC* = (X, เวลา, CC2, ชื่อโดเมน) v2-Hash = HMAC-MD5(NT-Hash, ชื่อผู้ใช้, ชื่อโดเมน) LMv2 = HMAC-MD5(v2-Hash, SC, CC) NTv2 = HMAC-MD5(v2-Hash, SC, CC*) การตอบสนอง = LMv2 | CC | NTv2 | CC* 

โปรโตคอลเซสชัน NTLM2 คล้ายกับ MS-CHAPv2 ^{[ 17 ]} ประกอบด้วยการตรวจสอบสิทธิ์จาก NTLMv1 รวมกับความปลอดภัยของเซสชันจาก NTLMv2

โดยสรุปคือ จะใช้ขั้นตอนวิธี NTLMv1 แต่เพิ่มข้อมูลท้าทายจากฝั่งไคลเอ็นต์ขนาด 8 ไบต์ต่อท้ายข้อมูลท้าทายจากฝั่งเซิร์ฟเวอร์ขนาด 8 ไบต์ แล้วทำการแฮชด้วย MD5 ส่วนครึ่งหลังของผลลัพธ์การแฮชที่มีขนาดน้อยที่สุด 8 ไบต์ จะถูกนำมาใช้เป็นข้อมูลท้าทายในโปรโตคอล NTLMv1 ข้อมูลท้าทายจากฝั่งไคลเอ็นต์จะถูกส่งกลับมาในช่อง 24 ไบต์ช่องหนึ่งของข้อความตอบกลับ ส่วนข้อความตอบกลับที่คำนวณได้ขนาด 24 ไบต์จะถูกส่งกลับมาในช่องอีกช่องหนึ่ง

นี่เป็นรูปแบบที่แข็งแกร่งขึ้นของ NTLMv1 ซึ่งยังคงความสามารถในการใช้โครงสร้างพื้นฐานของตัวควบคุมโดเมนที่มีอยู่ แต่หลีกเลี่ยงการโจมตีพจนานุกรมโดยเซิร์ฟเวอร์ที่ไม่พึงประสงค์ สำหรับX ที่กำหนดไว้ เซิร์ฟเวอร์จะคำนวณตารางที่ตำแหน่งYมีค่าKโดยที่Y=DES_K(X)หากไม่มีไคลเอนต์เข้าร่วมในการเลือกความท้าทาย เซิร์ฟเวอร์สามารถส่งXค้นหาการตอบกลับYในตารางและรับKการโจมตีนี้สามารถทำได้จริงโดยใช้ตารางเรนโบว์^{[ 18 ]}

อย่างไรก็ตาม โครงสร้างพื้นฐาน NTLMv1 ที่มีอยู่เดิมนั้น อนุญาตให้คู่คำถาม/คำตอบไม่ได้รับการตรวจสอบโดยเซิร์ฟเวอร์ แต่จะส่งไปยังตัวควบคุมโดเมนเพื่อตรวจสอบแทน เมื่อใช้ NTLM2 Session โครงสร้างพื้นฐานนี้ยังคงทำงานได้ หากเซิร์ฟเวอร์ใช้ค่าแฮชของคำถามจากเซิร์ฟเวอร์และไคลเอ็นต์แทนคำถามหลัก

NTLMv1 ไคลเอ็นต์<-เซิร์ฟเวอร์: SC ไคลเอนต์->เซิร์ฟเวอร์: H(P,SC) เซิร์ฟเวอร์->DomCntl: H(P,SC), SC Server<-DomCntl: ใช่หรือไม่ เซสชั่น NTLM2 ไคลเอ็นต์<-เซิร์ฟเวอร์: SC ไคลเอนต์->เซิร์ฟเวอร์: H(P,H'(SC,CC)), CC Server->DomCntl: H(P,H'(SC,CC)), H'(SC,CC) Server<-DomCntl: ใช่หรือไม่ 

ตั้งแต่ปี 2010 เป็นต้นไป Microsoft ไม่แนะนำให้ใช้ NTLM ในแอปพลิเคชันอีกต่อไป: ^{[ 19 ]}

ผู้พัฒนาควรทราบว่า NTLM ไม่รองรับวิธีการเข้ารหัสลับรุ่นใหม่ ๆ เช่น AES หรือ SHA-256 โดยใช้การตรวจสอบความซ้ำซ้อนแบบวนรอบ (CRC) หรือMD5สำหรับการตรวจสอบความถูกต้อง และRC4สำหรับการเข้ารหัส

การสร้างคีย์จากรหัสผ่านเป็นไปตามที่ระบุไว้ใน RFC1320 และ FIPS46-2 ดังนั้นโดยทั่วไปแล้วจึงไม่แนะนำให้ใช้ NTLM กับแอปพลิเคชันต่างๆ

ถึงแม้จะมีคำแนะนำเหล่านี้ แต่ NTLM ก็ยังคงถูกใช้งานอย่างแพร่หลายในระบบต่างๆ เหตุผลหลักคือเพื่อรักษาความเข้ากันได้กับระบบรุ่นเก่า อย่างไรก็ตาม สามารถหลีกเลี่ยงการใช้งาน NTLM ได้ในบางสถานการณ์

ไมโครซอฟต์ได้เพิ่มแฮช NTLM ลงในการใช้งานโปรโตคอล Kerberosเพื่อปรับปรุงความสามารถในการทำงานร่วมกัน (โดยเฉพาะอย่างยิ่ง ประเภทการเข้ารหัส RC4-HMAC) ตามที่นักวิจัยอิสระระบุ การตัดสินใจออกแบบนี้ทำให้ Domain Controllers สามารถถูกหลอกให้ส่งตั๋ว Kerberos ให้กับผู้โจมตีได้ หากทราบแฮช NTLM ^{[ 20 ]} ไมโครซอฟต์ได้นำKerberos มา ใช้เป็นโปรโตคอลการตรวจสอบสิทธิ์ที่ต้องการสำหรับ Windows 2000 และโดเมน Active Directory รุ่นต่อมา^{[ 16 ]} โดยทั่วไปแล้ว Kerberos จะถูกใช้เมื่อเซิร์ฟเวอร์เป็นส่วนหนึ่งของโดเมน Windows Serverไมโครซอฟต์แนะนำให้นักพัฒนาไม่ใช้ Kerberos หรือ NTLM Security Support Provider (SSP) โดยตรง^{[ 21 ]}

แอปพลิเคชันของคุณไม่ควรเข้าถึงแพ็กเกจความปลอดภัย NTLM โดยตรง แต่ควรใช้แพ็กเกจความปลอดภัย Negotiate แทน Negotiate อนุญาตให้แอปพลิเคชันของคุณใช้ประโยชน์จากโปรโตคอลความปลอดภัยขั้นสูงได้ หากระบบที่เกี่ยวข้องกับการตรวจสอบสิทธิ์รองรับโปรโตคอลเหล่านั้น ปัจจุบัน แพ็กเกจความปลอดภัย Negotiate จะเลือกใช้ระหว่าง Kerberos และ NTLM โดยจะเลือก Kerberos เว้นแต่ว่าระบบใดระบบหนึ่งที่เกี่ยวข้องกับการตรวจสอบสิทธิ์ไม่สามารถใช้งานได้

NTLM SSP ใช้ในสถานการณ์ต่อไปนี้:

• ไคลเอนต์กำลังตรวจสอบสิทธิ์กับเซิร์ฟเวอร์ที่ไม่ได้อยู่ในโดเมน หรือไม่มีโดเมน Active Directory อยู่ (โดยทั่วไปเรียกว่า "เวิร์กกรุ๊ป" หรือ "เพียร์ทูเพียร์")
  • เซิร์ฟเวอร์ต้องเปิดใช้งานคุณสมบัติ "การแชร์ที่ป้องกันด้วยรหัสผ่าน" ซึ่งโดยปกติจะไม่เปิดใช้งาน และไม่สามารถใช้งานร่วมกับ HomeGroup ได้ใน Windows บางเวอร์ชัน
  • เมื่อเซิร์ฟเวอร์และไคลเอ็นต์อยู่ในHomeGroup เดียวกัน โปรโตคอลที่คล้ายกับ Kerberos ซึ่งเป็นการตรวจสอบสิทธิ์ผู้ใช้ต่อผู้ใช้โดยใช้การเข้ารหัสคีย์สาธารณะจะถูกนำมาใช้แทน NTLM ^{[ 22 ]} HomeGroup น่าจะเป็นวิธีที่ง่ายที่สุดในการแชร์ทรัพยากรบนเครือข่ายขนาดเล็ก โดยต้องการการตั้งค่าเพียงเล็กน้อย แม้แต่เมื่อเทียบกับการกำหนดค่าผู้ใช้เพิ่มเติมอีกไม่กี่รายเพื่อให้สามารถใช้การแชร์ที่ป้องกันด้วยรหัสผ่าน ซึ่งอาจหมายความว่ามีการใช้งานมากกว่าการแชร์ที่ป้องกันด้วยรหัสผ่านบนเครือข่ายขนาดเล็กและเครือข่ายภายในบ้าน
• หากเซิร์ฟเวอร์เป็นอุปกรณ์ที่รองรับSMBเช่น อุปกรณ์ NAS และเครื่องพิมพ์เครือข่าย NTLM SSP อาจเป็นวิธีการตรวจสอบสิทธิ์เพียงวิธีเดียวที่รองรับ การใช้งาน SMB บางอย่างหรือระบบปฏิบัติการSamba รุ่นเก่า อาจทำให้ Windows เจรจา NTLMv1 หรือแม้แต่ LM สำหรับการตรวจสอบสิทธิ์ขาออกกับเซิร์ฟเวอร์ SMB ทำให้เครื่องสามารถทำงานได้แม้ว่าจะมีซอฟต์แวร์ที่ล้าสมัยและไม่ปลอดภัยติดตั้งอยู่ก็ตาม ไม่ว่าจะเป็นอุปกรณ์ใหม่หรือไม่ก็ตาม
• หากเซิร์ฟเวอร์เป็นสมาชิกของโดเมน แต่ไม่สามารถใช้ Kerberos ได้
  • ไคลเอนต์กำลังยืนยันตัวตนกับเซิร์ฟเวอร์โดยใช้ที่อยู่ IP (และไม่มีการแปลงชื่อย้อนกลับ)
  • ไคลเอนต์กำลังตรวจสอบสิทธิ์กับเซิร์ฟเวอร์ที่อยู่ในฟอเรสต์ Active Directory ที่แตกต่างกัน ซึ่งใช้การเชื่อมต่อแบบ NTLM เดิม แทนที่จะเป็นการเชื่อมต่อแบบทรานซิทีฟระหว่างฟอเรสต์
  • โดยปกติแล้วไฟร์วอลล์จะจำกัดพอร์ตที่จำเป็นสำหรับ Kerberos (โดยทั่วไปคือ TCP 88)

หลังจากที่นักพัฒนาแอปพลิเคชันหรือ Negotiate SSP ตัดสินใจแล้วว่าจะใช้ NTLM SSP สำหรับการตรวจสอบสิทธิ์นโยบายกลุ่มจะกำหนดความสามารถในการใช้โปรโตคอลแต่ละตัวที่ NTLM SSP นำไปใช้ มีระดับการตรวจสอบสิทธิ์ห้าระดับ^{[ 23 ]}

• ส่งการตอบกลับ LM และ NTLM : ไคลเอ็นต์ใช้การตรวจสอบสิทธิ์ LM และ NTLM และไม่ใช้การรักษาความปลอดภัยเซสชัน NTLMv2 เลย ตัวควบคุมโดเมนยอมรับการตรวจสอบสิทธิ์ LM, NTLM และ NTLMv2
• ส่ง LM และ NTLM - ใช้การรักษาความปลอดภัยเซสชัน NTLMv2 หากมีการเจรจา : ไคลเอ็นต์ใช้การตรวจสอบสิทธิ์ LM และ NTLM และใช้การรักษาความปลอดภัยเซสชัน NTLMv2 หากเซิร์ฟเวอร์รองรับ; DC ยอมรับการตรวจสอบสิทธิ์ LM, NTLM และ NTLMv2
• ส่งการตอบกลับ NTLM เท่านั้น : ไคลเอ็นต์ใช้การตรวจสอบสิทธิ์ NTLM เท่านั้น และใช้การรักษาความปลอดภัยเซสชัน NTLMv2 หากเซิร์ฟเวอร์รองรับ; DC ยอมรับการตรวจสอบสิทธิ์ LM, NTLM และ NTLMv2
• ส่งการตอบกลับ NTLMv2 เท่านั้น : ไคลเอ็นต์ใช้การตรวจสอบสิทธิ์ NTLMv2 เท่านั้น และใช้การรักษาความปลอดภัยเซสชัน NTLMv2 หากเซิร์ฟเวอร์รองรับ; DC ยอมรับการตรวจสอบสิทธิ์ LM, NTLM และ NTLMv2
• ส่งการตอบกลับ NTLMv2 เท่านั้น/ปฏิเสธ LM : ไคลเอ็นต์ใช้การตรวจสอบสิทธิ์ NTLMv2 เท่านั้น และใช้การรักษาความปลอดภัยเซสชัน NTLMv2 หากเซิร์ฟเวอร์รองรับ; DC ปฏิเสธ LM (ยอมรับเฉพาะการตรวจสอบสิทธิ์ NTLM และ NTLMv2 เท่านั้น)
• ส่งการตอบกลับ NTLMv2 เท่านั้น / ปฏิเสธ LM และ NTLM : ไคลเอ็นต์ใช้การตรวจสอบสิทธิ์ NTLMv2 เท่านั้น และใช้การรักษาความปลอดภัยเซสชัน NTLMv2 หากเซิร์ฟเวอร์รองรับ; DC ปฏิเสธ LM และ NTLM (ยอมรับเฉพาะการตรวจสอบสิทธิ์ NTLMv2 เท่านั้น)

DC ย่อมาจาก Domain Controller แต่การใช้คำนั้นอาจทำให้สับสนได้ คอมพิวเตอร์ใดๆ ที่ทำหน้าที่เป็นเซิร์ฟเวอร์และตรวจสอบสิทธิ์ผู้ใช้ก็ถือเป็น DC ในบริบทนี้ได้เช่นกัน ตัวอย่างเช่น คอมพิวเตอร์ Windows ที่มีบัญชีผู้ใช้ภายในเครื่อง เช่น Administrator เมื่อใช้บัญชีนั้นในการล็อกอินผ่านเครือข่าย

ก่อน Windows NT 4.0 Service Pack 4 นั้น SSP จะทำการเจรจาใช้ NTLMv1 และจะเปลี่ยนไปใช้ LM หากเครื่องอีกฝ่ายไม่รองรับ

ตั้งแต่ Windows NT 4.0 Service Pack 4 เป็นต้นไป SSP จะเจรจาเซสชัน NTLMv2 เมื่อใดก็ตามที่ทั้งไคลเอ็นต์และเซิร์ฟเวอร์รองรับ^{[ 24 ]}จนถึง Windows XP จะใช้การเข้ารหัส 40 หรือ 56 บิตบนคอมพิวเตอร์ที่ไม่ใช่ของสหรัฐอเมริกา เนื่องจากสหรัฐอเมริกามีข้อจำกัดที่เข้มงวดเกี่ยวกับการส่งออกเทคโนโลยีการเข้ารหัสในขณะนั้น ตั้งแต่ Windows XP SP3 เป็นต้นไป สามารถเพิ่มการเข้ารหัส 128 บิตได้โดยการติดตั้งการอัปเดต และใน Windows 7 การเข้ารหัส 128 บิตจะเป็นค่าเริ่มต้น

ใน Windows Vista และเวอร์ชันที่สูงกว่า LM ถูกปิดใช้งานสำหรับการตรวจสอบสิทธิ์ขาเข้า ระบบปฏิบัติการที่ใช้ Windows NT จนถึง Windows Server 2003 จะจัดเก็บแฮชรหัสผ่านสองรายการ คือ แฮช LAN Manager (LM) และแฮช Windows NT ตั้งแต่Windows Vista เป็นต้นไป ความสามารถในการจัดเก็บทั้งสองรายการมีอยู่ แต่รายการหนึ่งจะถูกปิดใช้งานโดยค่าเริ่มต้น ซึ่งหมายความว่าการตรวจสอบสิทธิ์ LM จะไม่ทำงานอีกต่อไปหากคอมพิวเตอร์ที่ใช้ Windows Vista ทำหน้าที่เป็นเซิร์ฟเวอร์ Windows เวอร์ชันก่อนหน้า (ย้อนกลับไปถึง Windows NT 4.0 Service Pack 4) สามารถกำหนดค่าให้ทำงานในลักษณะนี้ได้ แต่ไม่ใช่ค่าเริ่มต้น^{[ 25 ]}

NTLM ยังคงมีความเสี่ยงต่อ การโจมตี แบบ pass the hashซึ่งเป็นรูปแบบหนึ่งของการโจมตีแบบ reflectionซึ่งได้รับการแก้ไขโดยการอัปเดตความปลอดภัยของ Microsoft MS08-068 ตัวอย่างเช่นMetasploitสามารถใช้ในหลายกรณีเพื่อรับข้อมูลประจำตัวจากเครื่องหนึ่งซึ่งสามารถนำไปใช้เพื่อควบคุมเครื่องอื่นได้^{[ 3 ] [ 26 ]} ชุดเครื่องมือ Squirtle สามารถใช้เพื่อใช้ประโยชน์จากการโจมตี แบบ cross-site scriptingบนเว็บไซต์เพื่อโจมตีสินทรัพย์ใกล้เคียงผ่าน NTLM ^{[ 27 ]}

ในเดือนกุมภาพันธ์ พ.ศ. 2553 Amplia Security ค้นพบข้อบกพร่องหลายประการในการใช้งานกลไกการตรวจสอบสิทธิ์ NTLM ของ Windows ซึ่งทำลายความปลอดภัยของโปรโตคอล ทำให้ผู้โจมตีสามารถเข้าถึงไฟล์แบบอ่าน/เขียนและเรียกใช้โค้ดจากระยะไกลได้ หนึ่งในการโจมตีที่นำเสนอคือความสามารถในการคาดเดาตัวเลขสุ่มเทียมและคำถาม/คำตอบที่สร้างโดยโปรโตคอล ข้อบกพร่องเหล่านี้มีอยู่ใน Windows ทุกเวอร์ชันมาเป็นเวลา 17 ปีแล้ว คำแนะนำด้านความปลอดภัยที่อธิบายปัญหาเหล่านี้รวมถึงตัวอย่างการโจมตีที่ใช้งานได้จริง ข้อบกพร่องทั้งหมดเหล่านี้ได้รับการแก้ไขโดย MS10-012 ^{[ 28 ] [ 29 ]}

ในปี 2012 ได้มีการสาธิตให้เห็นว่าการเรียงสับเปลี่ยนแฮชรหัสผ่าน NTLM 8 ตัวอักษรที่เป็นไปได้ทั้งหมดสามารถถอดรหัสได้ภายในเวลาไม่ถึง 6 ชั่วโมง^{[ 30 ]}

ในปี 2019 เวลาดังกล่าวลดลงเหลือประมาณ 2.5 ชั่วโมงโดยใช้ฮาร์ดแวร์ที่ทันสมัยกว่า^{[ 4 ] [ 31 ]}นอกจากนี้ตาราง Rainbowยังมีให้สำหรับรหัสผ่าน NTLM แปดและเก้าตัวอักษร รหัสผ่านที่สั้นกว่าสามารถกู้คืนได้ด้วยวิธีการโจมตีแบบ Brute Force ^{[ 32 ]}

ในปี 2019 EvilMog ^{[ 33 ] [ 34 ]}ได้เผยแพร่เครื่องมือที่เรียกว่า ntlmv1-multitool ^{[ 35 ]}เพื่อจัดรูปแบบการตอบสนองความท้าทาย NTLMv1 ในรูปแบบการถอดรหัสที่เข้ากันได้กับ hashcat ด้วยhashcatและพลัง GPU ที่เพียงพอ แฮช NTLM สามารถหาได้โดยใช้การโจมตีแบบข้อความธรรมดาที่ทราบโดยการถอดรหัสคีย์ DES ด้วยโหมด hashcat 14000 ดังที่ atom ^{[ 36 ]} ได้สาธิตไว้ ในฟอรัม hashcat

โปรดทราบว่าแฮชที่เทียบเท่ากับรหัสผ่านที่ใช้ในการโจมตีแบบ pass-the-hash และการถอดรหัสรหัสผ่านนั้นจะต้องถูก "ขโมย" มาก่อน (เช่น โดยการเจาะระบบที่มีสิทธิ์เพียงพอที่จะเข้าถึงแฮช) นอกจากนี้ แฮชเหล่านี้ยังไม่เหมือนกับ "แฮช" NTLMSSP_AUTH ที่ส่งผ่านเครือข่ายระหว่างการตรวจสอบสิทธิ์ NTLM แบบปกติด้วย

การใช้งาน NTLM สำหรับ Linux ได้แก่ Cntlm ^{[ 37 ]}และwinbind (ส่วนหนึ่งของSamba ) ^{[ 38 ]}อนุญาตให้แอปพลิเคชัน Linux ใช้พร็อกซี NTLM

FreeBSDยังรองรับการจัดเก็บรหัสผ่านผ่านCrypt (C)ในรูปแบบ NT-Hash ที่ไม่ปลอดภัยอีก ด้วย ^{[ 39 ]}

• ผู้จัดการ LAN
• เอ็นทีแอลเอ็มเอสเอสพี
• การตรวจสอบสิทธิ์ Windows แบบบูรณาการ
• เคอร์เบรอส

• การถอดรหัสแฮช NTLM ออนไลน์โดยใช้ตาราง Rainbow
• ข้อกำหนดโปรโตคอลการตรวจสอบสิทธิ์ NT LAN Manager (NTLM)
• Cntlm – พร็อกซีและตัวเร่งความเร็วการตรวจสอบสิทธิ์ NTLM, NTLMSR, NTLMv2พร็อกซี HTTP(S) และ SOCKS5 ส่วนบุคคลสำหรับแอปพลิเคชันที่ไม่รองรับ NTLM (Windows/Linux/UNIX)
• โปรโตคอลการตรวจสอบสิทธิ์ NTLM และผู้ให้บริการสนับสนุนด้านความปลอดภัยการวิเคราะห์โดยละเอียดของโปรโตคอล NTLM
• บทความจาก MSDN อธิบายเกี่ยวกับโปรโตคอลและแจ้งว่าได้มีการเปลี่ยนชื่อแล้ว
• หน้าเว็บ MSDN เกี่ยวกับการตรวจสอบสิทธิ์ NTLM
• Libntlm – การใช้งานแบบฟรี
• ซอฟต์แวร์ NTLM Authorization Proxy Serverที่ช่วยให้ผู้ใช้ยืนยันตัวตนผ่าน MS Proxy Server
• การติดตั้งระบบตรวจสอบสิทธิ์ NTLM – คำแนะนำการตั้งค่า NTLM สำหรับSambaและMidgardบนLinux
• NTLM เวอร์ชัน 2 (NTLMv2) และการตั้งค่า LMCompatibilityLevel ที่ควบคุมการทำงานของมัน
• Jespa – โซลูชันการผสานรวม Java กับ Active Directoryที่ให้บริการด้านความปลอดภัย NTLM อย่างเต็มรูปแบบ พร้อมการตรวจสอบ NETLOGON ฝั่งเซิร์ฟเวอร์ (เชิงพาณิชย์ แต่ใช้งานฟรีได้สูงสุด 25 ผู้ใช้)
• EasySSO - ตัวตรวจสอบสิทธิ์ NTML สำหรับ JIRAตัวตรวจสอบสิทธิ์ NTML ที่ใช้ ไลบรารี Jespaเพื่อให้บริการIWAสำหรับผลิตภัณฑ์Atlassian
• ntlmv2-authตัวกรอง API และ Servlet ของ NTLMv2 สำหรับ Java
• เครื่องมือสร้างข้อความ ntlm
• WAFFLE – เฟรมเวิร์กการตรวจสอบสิทธิ์ผู้ใช้บน Windows สำหรับ Java/C# เก็บถาวรเมื่อ 2010-10-20 ที่Wayback Machine
• objectif-securite (ตารางสีรุ้งสำหรับ ophcrack)
• Px สำหรับ Windows - เซิร์ฟเวอร์พร็อกซี HTTP ที่ตรวจสอบสิทธิ์โดยอัตโนมัติผ่านพร็อกซี NTLM
• NTLMv1 Multi Tool - เครื่องมือสำหรับจัดรูปแบบการตอบกลับการตรวจสอบ NTLMv1 ให้เป็นรูปแบบที่สามารถถอดรหัสได้ด้วย hashcat