Recent from talks
Contribute something
Nothing was collected or created yet.
LAN Manager
View on Wikipedia
| LAN Manager | |
|---|---|
| Developer | Microsoft, 3Com |
| OS family | OS/2 |
| Working state | Discontinued |
| Source model | Closed source |
| Initial release | 1987 |
| Final release | 2.2a / 1994 |
| Marketing target | Local area networking |
| Update method | Re-installation |
| Package manager | None |
| Supported platforms | x86 |
| License | Proprietary |
| Preceded by | MS-Net, Xenix-NET, 3+Share |
| Succeeded by | Microsoft Windows NT 3.1 |
LAN Manager is a discontinued network operating system (NOS) available from multiple vendors and developed by Microsoft in cooperation with 3Com Corporation. It was designed to succeed 3Com's 3+Share network server software which ran atop a heavily modified version of MS-DOS.
History
[edit]The LAN Manager OS/2 operating system was co-developed by IBM and Microsoft, using the Server Message Block (SMB) protocol. It originally used SMB atop either the NetBIOS Frames (NBF) protocol or a specialized version of the Xerox Network Systems (XNS) protocol. These legacy protocols had been inherited from previous products such as MS-Net for MS-DOS, Xenix-NET for MS-Xenix, and the afore-mentioned 3+Share. A version of LAN Manager for Unix-based systems called LAN Manager/X was also available. LAN Manager/X was the basis for Digital Equipment Corporation's Pathworks product for OpenVMS, Ultrix and Tru64.[1]
Despite support from 3Com, IBM, Digital, and Digital Communications Associates, PC wrote in 1989, LAN Manager "has made a very small impression on the market and continues to receive the cold shoulder from buyers" compared to Novell NetWare. The combined companies "pose a strong potential threat", however, the magazine added.[2] In 1990, Microsoft announced LAN Manager 2.0 with a host of improvements, including support for TCP/IP as a transport protocol for SMB, using NetBIOS over TCP/IP (NBT). The last version of LAN Manager, 2.2, which included an MS-OS/2 1.31 base operating system, remained Microsoft's strategic server system until the release of Windows NT Advanced Server in 1993.[3]
Versions
[edit]- 1987 – MS LAN Manager 1.0 (Basic/Enhanced)
- 1989 – MS LAN Manager 1.1
- 1991 – MS LAN Manager 2.0
- 1992 – MS LAN Manager 2.1
- 1992 – MS LAN Manager 2.1a
- 1993 – MS LAN Manager 2.2
- 1994 – MS LAN Manager 2.2a
Many vendors shipped licensed versions, including:
Password hashing algorithm
[edit]The LM hash is computed as follows:[4][5]
- The user's password is restricted to a maximum of fourteen characters.[Notes 1]
- The user's password is converted to uppercase.
- The user's password is encoded in the System OEM code page.[6]
- This password is NULL-padded to 14 bytes.[7]
- The “fixed-length” password is split into two 7-byte halves.
- These values are used to create two DES keys, one from each 7-byte half, by converting the seven bytes into a bit stream with the most significant bit first, and inserting a parity bit after every seven bits (so
1010100becomes10101000). This generates the 64 bits needed for a DES key. (A DES key ostensibly consists of 64 bits; however, only 56 of these are actually used by the algorithm. The parity bits added in this step are later discarded.) - Each of the two keys is used to DES-encrypt the constant ASCII string “
KGS!@#$%”,[Notes 2] resulting in two 8-byte ciphertext values. The DES CipherMode should be set to ECB, and PaddingMode should be set toNONE. - These two ciphertext values are concatenated to form a 16-byte value, which is the LM hash.
Security weaknesses
[edit]LAN Manager authentication uses a particularly weak method of hashing a user's password known as the LM hash algorithm, stemming from the mid-1980s when viruses transmitted by floppy disks were the major concern.[8] Although it is based on DES, a well-studied block cipher, the LM hash has several weaknesses in its design.[9] This makes such hashes crackable in a matter of seconds using rainbow tables, or in a few minutes using brute force. Starting with Windows NT, it was replaced by NTLM, which is still vulnerable to rainbow tables, and brute force attacks unless long, unpredictable passwords are used, see password cracking. NTLM is used for logon with local accounts except on domain controllers since Windows Vista and later versions no longer maintain the LM hash by default.[8] Kerberos is used in Active Directory Environments.
The major weaknesses of LAN Manager authentication protocol are:[10]
- Password length is limited to a maximum of 14 characters chosen from the 95 ASCII printable characters.
- Passwords are not case sensitive. All passwords are converted into uppercase before generating the hash value. Hence LM hash treats PassWord, password, PaSsWoRd, PASSword and other similar combinations same as PASSWORD. This practice effectively reduces the LM hash key space to 69 characters.
- A 14-character password is broken into 7+7 characters and the hash is calculated for each half separately. This way of calculating the hash makes it dramatically easier to crack, as the attacker only needs to brute-force 7 characters twice instead of the full 14 characters. This makes the effective strength of a 14-character password equal to only , or twice that of a 7-character password, which is 3.7 trillion times less complex than the theoretical strength of a 14-character single-case password. As of 2020, a computer equipped with a high-end graphics processor (GPUs) can compute 40 billion LM-hashes per second.[11] At that rate, all 7-character passwords from the 95-character set can be tested and broken in half an hour; all 7-character alphanumeric passwords can be tested and broken in 2 seconds.
- If the password is 7 characters or less, then the second half of hash will always produce same constant value (0xAAD3B435B51404EE). Therefore, a password is less than or equal to 7 characters long can be identified visibly without using tools (though with high speed GPU attacks, this matters less).
- The hash value is sent to network servers without salting, making it susceptible to man-in-the-middle attacks such as replay the hash. Without salt, time–memory tradeoff pre-computed dictionary attacks, such as a rainbow table, are feasible. In 2003, Ophcrack, an implementation of the rainbow table technique, was published. It specifically targets the weaknesses of LM encryption, and includes pre-computed data sufficient to crack virtually all alphanumeric LM hashes in a few seconds. Many cracking tools, such as RainbowCrack, Hashcat, L0phtCrack and Cain, now incorporate similar attacks and make cracking of LM hashes fast and trivial.
Workarounds
[edit]To address the security weaknesses inherent in LM encryption and authentication schemes, Microsoft introduced the NTLMv1 protocol in 1993 with Windows NT 3.1. For hashing, NTLM uses Unicode support, replacing LMhash=DESeach(DOSCHARSET(UPPERCASE(password)), "KGS!@#$%") by NThash=MD4(UTF-16-LE(password)), which does not require any padding or truncating that would simplify the key. On the negative side, the same DES algorithm was used with only 56-bit encryption for the subsequent authentication steps, and there is still no salting. Furthermore, Windows machines were for many years configured by default to send and accept responses derived from both the LM hash and the NTLM hash, so the use of the NTLM hash provided no additional security while the weaker hash was still present. It also took time for artificial restrictions on password length in management tools such as User Manager to be lifted.
While LAN Manager is considered obsolete and current Windows operating systems use the stronger NTLMv2 or Kerberos authentication methods, Windows systems before Windows Vista/Windows Server 2008 enabled the LAN Manager hash by default for backward compatibility with legacy LAN Manager and Windows ME or earlier clients, or legacy NetBIOS-enabled applications. It has for many years been considered good security practice to disable the compromised LM and NTLMv1 authentication protocols where they aren't needed.[12] Starting with Windows Vista and Windows Server 2008, Microsoft disabled the LM hash by default; the feature can be enabled for local accounts via a security policy setting, and for Active Directory accounts by applying the same setting via domain Group Policy. The same method can be used to turn the feature off in Windows 2000, Windows XP and NT.[12] Users can also prevent a LM hash from being generated for their own password by using a password at least fifteen characters in length.[7]—NTLM hashes have in turn become vulnerable in recent years to various attacks that effectively make them as weak today as LanMan hashes were back in 1998.[citation needed]
Reasons for continued use of LM hash
[edit]Many legacy third party SMB implementations have taken considerable time to add support for the stronger protocols that Microsoft has created to replace LM hashing because the open source communities supporting these libraries first had to reverse engineer the newer protocols—Samba took 5 years to add NTLMv2 support, while JCIFS took 10 years.
| Product | NTLMv1 support | NTLMv2 support |
|---|---|---|
| Windows NT 3.1 | RTM (1993) | Not supported |
| Windows NT 3.5 | RTM (1994) | Not supported |
| Windows NT 3.51 | RTM (1995) | Not supported |
| Windows NT 4 | RTM (1996) | Service Pack 4[13] (October 25, 1998) |
| Windows 95 | Not supported | Directory services client (released with Windows 2000 Server, February 17, 2000) |
| Windows 98 | RTM | Directory services client (released with Windows 2000 Server, February 17, 2000) |
| Windows 2000 | RTM (February 17, 2000) | RTM (February 17, 2000) |
| Windows Me | RTM (September 14, 2000) | Directory services client (released with Windows 2000 Server, February 17, 2000) |
| Samba | ? | Version 3.0[14] (September 24, 2003) |
| JCIFS | Not supported | Version 1.3.0 (October 25, 2008)[15] |
| IBM AIX (SMBFS) | 5.3 (2004)[16] | Not supported as of v7.1[17] |
Poor patching regimes subsequent to software releases supporting the feature becoming available have contributed to some organisations continuing to use LM Hashing in their environments, even though the protocol is easily disabled in Active Directory itself.
Lastly, prior to the release of Windows Vista, many unattended build processes still used a DOS boot disk (instead of Windows PE) to start the installation of Windows using WINNT.EXE, something that requires LM hashing to be enabled for the legacy LAN Manager networking stack to work.
See also
[edit]Notes
[edit]- ^ If the password is more than fourteen characters long, the LM hash cannot be computed.
- ^ The string “KGS!@#$%” could possibly mean Key of Glen and Steve and then the combination of Shift + 12345. Glen Zorn and Steve Cobb are the authors of RFC 2433 (Microsoft PPP CHAP Extensions).
References
[edit]- ^ Andy Goldstein (2005). "Samba and OpenVMS" (PDF). de.openvms.org. Archived from the original (PDF) on February 7, 2021. Retrieved January 1, 2021.
- ^ Derfler, Frank J. Jr.; Thompson, M. Keith (December 12, 1989). "Novell's NetWare 386". PC Magazine. Vol. 8, no. 21. p. 205. Retrieved May 2, 2025.
- ^ "DOS SMB Client Performance | OS/2 Museum". Retrieved August 28, 2023.
- ^ "Chapter 3 - Operating System Installation". Microsoft Docs. March 24, 2009. The LMHash. Retrieved October 16, 2023.
- ^ Glass, Eric (2006). "The NTLM Authentication Protocol and Security Support Provider: The LM Response". Retrieved May 12, 2015.
- ^ "List of Localized MS Operating Systems". Microsoft Developer Network. Archived from the original on May 18, 2015. Retrieved May 12, 2015.
- ^ a b "Cluster service account password must be set to 15 or more characters if the NoLMHash policy is enabled". Microsoft. October 30, 2006. Archived from the original on September 10, 2014. Retrieved May 12, 2015.
- ^ a b Jesper Johansson (August 31, 2016). "The Most Misunderstood Windows Security Setting of All Time". Microsoft Docs. Microsoft. Retrieved October 16, 2023.
Although Windows Vista has not been released yet, it is worthwhile to point out some changes in this operating system related to these protocols. The most important change is that the LM protocol can no longer be used for inbound authentication—where Windows Vista is acting as the authentication server.
- ^ Johansson, Jasper M. (June 29, 2004). "Windows Passwords: Everything You Need To Know". Microsoft. Retrieved May 12, 2015.
- ^ Rahul Kokcha
- ^ Benchmark Hashcat v6.1.1 on RTX 2070S (SUPER), Mode 3000 LM, accessed November 29, 2020
- ^ a b "How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases". Microsoft Docs. December 3, 2007. Retrieved October 16, 2023.
- ^ "Windows NT 4.0 Service Pack 4 Readme.txt File (40-bit)". Microsoft. October 25, 1998. Archived from the original on May 19, 2015. Retrieved May 12, 2015.
- ^ "The Samba Team announces the first official release of Samba 3.0". SAMBA. September 24, 2003. Retrieved May 12, 2015.
- ^ "The Java CIFS Client Library". Archived from the original on May 10, 2015. Retrieved May 12, 2015.
- ^ "AIX 5.3 Networks and communication management: Server Message Block file system". IBM. March 15, 2010. p. 441. Retrieved May 12, 2015.
- ^ "AIX 7.1 Networks and communication management: Server Message Block file system". IBM. December 5, 2011. Retrieved May 12, 2015.
External links
[edit]- 1.3.8.1.1 Microsoft LAN Manager at the Wayback Machine (archived February 12, 2017)
- "Microsoft LAN Manager User's Guide for MS-DOS" (PDF) – via Bitsavers.
LAN Manager
View on GrokipediaIntroduction
Overview
LAN Manager is a network operating system (NOS) developed by Microsoft in cooperation with 3Com Corporation and announced in 1987, first released in 1988 for the OS/2 operating system, designed to enable file, printer, and resource sharing over local area networks (LANs).[6][7] It provided a client-server architecture that allowed multiple users to access shared resources transparently, supporting both OS/2 servers and clients while facilitating centralized management of network services.[8] Primarily targeted at small to medium-sized business networks, LAN Manager integrated seamlessly with MS-DOS and OS/2 clients, enabling cost-effective deployment in workgroup environments without requiring dedicated hardware for every user.[6][7] This made it suitable for environments needing straightforward resource sharing, such as office file servers and print queues, while offering user-level and share-level security to control access.[8] At its core, LAN Manager was built on the Server Message Block (SMB) protocol, ensuring backward compatibility with earlier Microsoft networking products like MS-NET and allowing interoperability across diverse systems via NetBIOS and other transports.[2] Initially positioned as a direct competitor to Novell NetWare, it emphasized support for multi-vendor hardware, including adapters from 3Com, IBM, and Digital Equipment Corporation, to broaden adoption in heterogeneous LAN setups.[9][8] It later transitioned into the networking foundation for Windows NT as Microsoft's successor platform.[10]Historical Significance
In the late 1980s, the rapid emergence of PC-based local area networks (LANs) revolutionized business computing by facilitating resource sharing, such as files and printers, across affordable personal computers connected via Ethernet or Token-Ring technologies. This shift was driven by falling hardware costs and the need for distributed processing in enterprises, with global LAN product sales surpassing $5 billion in 1989 and projected to double by the mid-1990s. Amid this growth, competition intensified among network operating systems, where Novell's NetWare established dominance with over 70% market share by the early 1990s, far outpacing rivals like Banyan VINES and Microsoft's LAN Manager.[11][12] Microsoft's LAN Manager, announced in 1987 in partnership with 3Com for OS/2 and first released in 1988, marked the company's ambitious push into enterprise networking but encountered limited commercial adoption. Bundled with later iterations like version 2.1 alongside MS OS/2 1.3, it captured only about 8% of the market by 1991, hindered by NetWare's superior performance, broader vendor ecosystem, and established reliability in PC environments. Despite these challenges, LAN Manager's integration with OS/2 positioned it as a foundational tool for early multiserver setups, though it remained a niche player overshadowed by NetWare's commanding presence.[13][11] LAN Manager's enduring influence within the Microsoft ecosystem stemmed from its implementation of the Server Message Block (SMB) protocol atop NetBIOS, which standardized file and print sharing for OS/2-based networks and set the stage for broader adoption. This architecture directly informed Windows NT's networking stack, where SMB was ported alongside components like named pipes originally developed for LAN Manager, enabling seamless evolution toward integrated enterprise solutions. These advancements contributed to the foundations of Active Directory by embedding SMB as a core mechanism for domain-based resource access in subsequent Windows releases.[2][14][15] The product's long-term legacy lies in pioneering client-server models that made networked computing accessible to mainstream businesses, fostering the shift from standalone PCs to interconnected environments. Although deprecated, remnants of LAN Manager's SMB framework persist in modern Windows implementations, supporting backward compatibility and file-sharing protocols essential to contemporary enterprise networking. For instance, LAN Manager 2.0's addition of TCP/IP support in 1990 briefly enhanced its cross-protocol viability before Microsoft's pivot to NT.[2][13]Development and History
Origins and Partnerships
LAN Manager originated as a collaborative effort between Microsoft and 3Com Corporation, initiated in 1987 to create an advanced network operating system. This partnership built upon 3Com's existing networking expertise, particularly leveraging their 3Server hardware—a dedicated server platform introduced earlier in the mid-1980s for running network services like the 3+Share software. The joint development aimed to produce a robust solution for enterprise networking, with 3Com serving as a key original equipment manufacturer (OEM) for early distributions. It was licensed to additional third-party vendors including Hewlett-Packard, Nokia Data Systems, and Ungermann-Bass.[16][13][17][1] The system was specifically designed for IBM's OS/2 operating system, with OS/2 1.0 released in December 1987, as an extension of Microsoft's earlier MS-NET product from 1984. MS-NET had provided basic peer-to-peer networking for MS-DOS environments but was limited to single-user workstations without centralized management. LAN Manager advanced this by introducing multi-user server capabilities on OS/2, enabling scalable file and print sharing in larger workgroups. This integration with OS/2 stemmed from the close collaboration between Microsoft and IBM, who co-developed the OS/2 platform, ensuring seamless compatibility for business applications.[13][18][16][19] Partnerships expanded beyond the initial Microsoft-3Com alliance to include IBM for deeper OS/2 integration and Digital Equipment Corporation (DEC) for DECnet compatibility, facilitating interoperability across diverse hardware and protocols. Additional collaborations with hardware vendors ensured broad support for Ethernet and other LAN technologies, allowing LAN Manager to run on various server platforms without proprietary lock-in. These alliances were crucial for achieving hardware interoperability in heterogeneous environments.[13][20][21] The primary motivations for LAN Manager's development were to overcome the constraints of single-user MS-DOS networking, such as limited scalability and lack of centralized control in MS-NET. By introducing domain-based administration and dedicated server roles, it enabled efficient management of multiple users and resources, positioning it as a direct competitor to Novell NetWare in enterprise settings. This shift toward server-centric architecture addressed the growing demand for reliable, multi-user LANs in professional environments.[16][18][22]Versions and Evolution
Microsoft LAN Manager 1.0 was initially released in October 1987 as an OEM product, providing basic support for SMB over NetBIOS protocols and targeting OS/2 environments for file and print sharing.[1] Developed in partnership with 3Com, this version focused on local area networking for workstations and servers, with early implementations like 3Com's 3+Open appearing in 1988.[13] In 1989, LAN Manager 1.1 enhanced integration with OS/2 1.1, introducing improved client support for both DOS and OS/2 systems while retaining NetBIOS as the primary transport.[7] This update emphasized better multi-protocol handling, including Xerox Network Systems (XNS) compatibility, to broaden interoperability in heterogeneous networks.[7] The major evolution came with version 2.0 in 1990, which added TCP/IP stack support via Microsoft TCP/IP-32, shifting from reliance on XNS and NetBIOS toward broader internetworking compatibility.[13] This release also introduced domain controllers for centralized user and resource management, marking a step toward scalable enterprise networking on OS/2 1.21.[13] Subsequent updates, including 2.1 in November 1991 and 2.1a in August 1992, focused on performance optimizations and bug fixes to enhance reliability in server environments.[23] By 1993, LAN Manager 2.2 extended support to Windows clients, incorporating MS-OS/2 1.31 as the base OS and further refining TCP/IP integration for mixed-platform deployments.[1] The final update, 2.2a in 1994, delivered additional bug fixes and stability improvements, primarily for MS-DOS workstations via LAN Manager for MS-DOS.[24] Platform expansions during this period included ports to MS-DOS for client use and a UNIX variant, LAN Manager/X, developed with 3Com for System V environments to enable cross-OS file sharing.[25] Development of LAN Manager ceased after the 2.2a release in 1994, with mainstream support ending by 1996 as Windows NT 3.1—released in 1993—assumed the role of Microsoft's primary network operating system, incorporating evolved authentication like NTLM.[26]Technical Architecture
Networking Protocols
LAN Manager primarily utilized the Server Message Block (SMB) protocol layered over NetBIOS Frames (NBF) to handle session management and data transfer across the network. This combination enabled reliable communication for file and printer sharing in early client-server environments, with SMB providing the application-layer semantics and NBF encapsulating NetBIOS datagrams over Ethernet or other LAN media.[27] In its initial version 1.0, LAN Manager supported alternative protocol stacks, including a specialized implementation of the Xerox Network Systems (XNS) protocol suite for transport, which allowed compatibility with Xerox-based networks alongside the standard NetBIOS option. Starting with version 2.0, enhancements introduced TCP/IP integration, supporting NetBEUI (NetBIOS Extended User Interface) as an intermediary for NetBIOS over TCP/IP or direct IP transport for SMB sessions, broadening interoperability with IP-based infrastructures.[28][13] Key protocol features included opportunistic locking (oplocks) within SMB, which permitted clients to cache file data locally for improved performance in single-user scenarios while coordinating with the server to break locks if conflicts arose. The redirector architecture facilitated client-server interactions by intercepting file system calls and routing them transparently over the network, abstracting remote resources as local drives. Name resolution relied on broadcast-based NetBIOS mechanisms, where clients sent datagram broadcasts to discover servers by name on the local segment.[29][30][27] For physical layer interoperability, LAN Manager was designed to operate over both Ethernet and Token Ring networks, leveraging the Network Driver Interface Specification (NDIS) for modular driver support that enabled third-party network interface cards without kernel modifications. This API-driven approach ensured adaptability to diverse hardware while maintaining consistent upper-layer protocol behavior.[31]Core Services
LAN Manager provided essential network operating system services for resource sharing and management in enterprise environments, enabling centralized control over files, printers, and user access across interconnected workstations. These core services were built on the OS/2 platform and facilitated seamless integration for multi-user operations, supporting up to 255 concurrent users per server through configurable limits.[32] The file services in LAN Manager offered a hierarchical file system based on the High-Performance File System (HPFS386), a 32-bit structure with enhanced caching for efficient data handling and support for long filenames. Access to shared resources was managed through access control lists (ACLs), which allowed administrators to define granular permissions such as read (R), write (W), create (C), execute (X), delete (D), alter permissions (A), and take ownership (P) for directories and files, with inherited permissions propagating down the hierarchy. For redundancy, the system included volume shadowing capabilities via disk mirroring and duplexing, ensuring data availability in case of hardware failures. These services were delivered primarily over the Server Message Block (SMB) protocol for transparent file operations.[22][32] Print services featured a centralized spooler with robust queue management, allowing multiple queues per printer to handle jobs with varying priorities, including options to hold, release, delete, and monitor status for efficient workflow control. Administrators could configure form types and enable automatic font downloads for compatibility with PostScript and LaserJet printers, while raw data redirection supported non-standard devices through network ports like LPT1-LPT3. This setup enabled shared printing across domains, reducing the need for local attachments and streamlining output in networked offices.[22][32] Administrative tools in LAN Manager centered on domain-based user account management, where primary and backup domain controllers maintained centralized authentication and group policies to enforce security settings like password expiration rules and access restrictions. User and group accounts were created and overseen via command-line utilities, such as the NET commands (e.g.,NET USER for account creation, NET GROUP for membership), which also supported server monitoring through real-time status displays and performance metrics. Additional monitoring included integration with uninterruptible power supplies (UPS) for alert notifications and tools like NET WHO to track active users, providing administrators with comprehensive oversight without graphical interfaces in early versions.[22][32]
Client integration was achieved through redirectors in the Workstation service, which enabled MS-DOS and OS/2 workstations to access shared resources transparently as if they were local drives or ports, using commands like NET USE to map network paths (e.g., \\server\share to a drive letter). This supported both enhanced and basic redirector modes for compatibility with diskless workstations, allowing boot-up and operation without local storage while maintaining full access to file and print services.[22][32]
Authentication System
Password Hashing Algorithm
The LAN Manager (LM) password hashing algorithm processes user passwords to generate a 16-byte hash value used for authentication in network environments. The input password is first converted to uppercase letters to ensure case-insensitivity, then truncated to a maximum of 14 characters if longer or padded with null bytes (0x00) if shorter, resulting in exactly 14 bytes. This 14-byte value is subsequently split into two 7-byte halves, with each half serving as the basis for a DES key derivation.[33][34] Hash generation employs the Data Encryption Standard (DES) algorithm in Electronic Codebook (ECB) mode without salting, iteration, or additional security enhancements. Each 7-byte half is expanded into a 64-bit DES key by selecting 56 data bits (skipping every eighth bit for parity adjustment) and appending 8 parity bits. These two DES keys are then used to encrypt the fixed 8-byte plaintext string "KGS!@#$%" (ASCII values: 0x4B 0x47 0x53 0x21 0x40 0x23 0x24 0x25), producing two 8-byte ciphertext blocks. The LM hash is the concatenation of these blocks, yielding a 16-byte output. This process can be formally expressed as: \text{LM}(P) = \text{DES}(K_1, \, \text{"KGS!@\$%"} ) \, \| \, \text{DES}(K_2, \, \text{"KGS!@\$%"} ) where is the processed 14-byte password, and are the 64-bit DES keys derived from the first and second 7-byte halves, respectively, denotes concatenation, and DES operates as a single encryption without padding modifications.[33][34] The resulting 16-byte LM hash is stored in the local Security Accounts Manager (SAM) database alongside the stronger NT hash for backward compatibility in Windows systems. In the Server Message Block (SMB) protocol, this hash facilitates challenge-response authentication: the server generates and sends an 8-byte random challenge to the client, which derives three DES keys from the LM hash (appended with five null bytes) to encrypt the challenge, producing a 24-byte response sent back for server verification. This design, while simple, introduces vulnerabilities due to its weak cryptographic properties, such as the lack of salting.[35][36]Security Vulnerabilities
One of the primary flaws in LAN Manager's authentication system stems from its handling of passwords, which are converted to uppercase, rendering the mechanism case-insensitive and significantly reducing the complexity of potential passwords. Additionally, passwords are limited to a maximum of 14 characters, padded with null bytes if shorter, and then split into two independent 7-character halves for processing. This design choice drastically shrinks the effective keyspace for brute-force attacks to approximately 2^43 possibilities per half (total effective keyspace of about 2^44 for the full hash), as each half can be attacked separately using the limited character set of about 69 possibilities per position (uppercase letters A–Z, digits 0–9, and 33 common symbols).[37][38] The encryption employed in LAN Manager hashing further exacerbates these vulnerabilities by relying on a single pass of the Data Encryption Standard (DES) algorithm for each password half, producing an 8-byte ciphertext per segment that is concatenated into a 16-byte hash. This weak cryptographic primitive, combined with the absence of salting, makes the hashes susceptible to efficient brute-force attacks; modern graphics processing units (GPUs) can exhaust the reduced keyspace and crack a full LM hash in mere minutes or even seconds for simpler passwords. Moreover, the lack of salt enables the use of precomputed rainbow tables, such as those distributed by Ophcrack, which store mappings of hashes to plaintexts and can recover most LM hashes almost instantaneously due to the deterministic nature of unsalted DES.[38][37][39] Transmission of authentication data in LAN Manager introduces additional risks, as the challenge-response exchanges (including the 24-byte LM response derived from the LM hash) are sent over the network without additional encryption, allowing interception via packet sniffing. This exposure facilitates pass-the-hash attacks, where captured LM hashes (typically extracted from memory or storage) can be used to compute responses and authenticate to other systems without deriving the original password, bypassing standard credential checks in compatible environments. Furthermore, the protocol's reliance on broadcast-based discovery mechanisms, such as NetBIOS over TCP/IP, broadcasts session announcements across local networks, potentially revealing active LM-authenticated sessions to eavesdroppers and aiding in targeted exploitation.[40] Historical exploits underscore the long-standing exploitability of these flaws, with tools like L0phtCrack—released in 1997 by the L0pht Heavy Industries group—demonstrating the ability to rapidly crack LM hashes extracted from network captures or system dumps using dictionary and brute-force methods, often recovering passwords in minutes on contemporary hardware. These weaknesses persisted in implementations beyond Microsoft systems, notably in the open-source Samba project, where support for LM hashing continued in legacy configurations until the adoption of NTLMv2 as the default around 2007, when efforts to disable weak lanman hash generation by default were formalized.[41][42]Mitigation and Legacy
Workarounds and Improvements
To address the security weaknesses inherent in LAN Manager's authentication mechanisms, administrators could enforce password policies requiring at least 15 characters, which prevents the generation of an LM hash altogether by producing a null value instead.[35] This approach leverages the limitation of LM hashing, which truncates passwords to 14 uppercase characters, ensuring that longer passphrases bypass the vulnerable DES-based computation entirely.[43] Evolutionary upgrades to the protocol provided more robust alternatives, starting with the transition to NTLMv1 in 1993, which replaced LM's weak DES encryption with MD4 hashing and supported Unicode for broader character compatibility.[44] Further improvements came with NTLMv2 in 1997, incorporating HMAC-MD5 for enhanced integrity and mutual authentication to mitigate risks like replay attacks.[45] By Windows 2000, Microsoft introduced full Kerberos support as the preferred protocol, offering ticket-based authentication with stronger cryptographic protections.[44] These changes were prompted by legacy vulnerabilities in LM that exposed passwords to offline cracking.[44] Configuration options allowed fine-grained control over LM usage, such as setting the registry keyNoLMHash=1 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa starting with Windows 2000 to prevent storage of LM hashes on password changes.[46] Additionally, Group Policy settings for Network security: LAN Manager authentication level provided escalation from level 0 (allowing LM, NTLM, and NTLMv2) to level 5 (NTLMv2 only, rejecting LM and NTLMv1), with levels 3 and above explicitly denying LM responses.[47]
In modern environments, LM hashing was disabled by default in Windows Vista and Windows Server 2008 released in 2007, eliminating its storage without manual intervention.[35] Further deprecation progressed with stricter enforcement in Windows 11 from 2021 onward, culminating in its effective removal from active support, and Security Technical Implementation Guides (STIGs) mandating its disablement as of 2025 to align with compliance standards.[48]
