Jump to content

LAN Manager

From Alfawiki
LAN Manager
Company typeDiscontinued software
IndustryNetwork operating system
Predecessor3+Share
Founded1987
FounderMicrosoft and 3Com Corporation
FateDiscontinued; succeeded by Windows NT Advanced Server
ProductsNetwork operating system software
ParentMicrosoft, 3Com Corporation

LAN Manager was a network operating system (NOS) developed jointly by Microsoft and 3Com Corporation, now discontinued. It served as a successor to 3Com's 3+Share server software, which operated on a customized MS-DOS platform.

History

The LAN Manager system, built on the OS/2 platform, was a collaborative effort between IBM and Microsoft. It utilized the Server Message Block (SMB) protocol, initially running SMB over either the NetBIOS Frames (NBF) protocol or a proprietary variant of the Xerox Network Systems (XNS) protocol. This approach drew from earlier technologies such as MS-Net for MS-DOS, Xenix-NET for MS-Xenix, and 3+Share. Additionally, a Unix-based edition named LAN Manager/X existed, which laid the groundwork for Digital Equipment Corporation’s Pathworks solutions compatible with OpenVMS, Ultrix, and Tru64.

Although supported by major companies including 3Com, IBM, Digital, and Digital Communications Associates, PC observed in 1989 that LAN Manager had a limited market impact compared to rivals like Novell NetWare. Nevertheless, the alliance of these firms posed a considerable competitive challenge. In 1990, Microsoft introduced LAN Manager 2.0, incorporating major improvements such as enabling SMB to operate over TCP/IP through the use of NetBIOS over TCP/IP (NBT). The final release, version 2.2, which was based on MS-OS/2 1.31, remained Microsoft’s main server platform until it was succeeded by Windows NT Advanced Server in 1993.

Versions

  • 1987 – MS LAN Manager 1.0 (Basic and Enhanced editions)
  • 1989 – MS LAN Manager 1.1
  • 1991 – MS LAN Manager 2.0
  • 1992 – MS LAN Manager 2.1 and 2.1a
  • 1993 – MS LAN Manager 2.2
  • 1994 – MS LAN Manager 2.2a

Various licensed versions were distributed by companies such as:

  • 3Com (3+Open)
  • HP LAN Manager/X
  • IBM LAN Server
  • Tapestry Torus
  • Santa Cruz Operation

Password hashing algorithm

The generation of the LM hash follows these steps:

  1. Passwords are restricted to a maximum length of fourteen characters.
  2. All password characters are converted to uppercase.
  3. The password string is encoded using the system’s OEM code page.
  4. The password is padded with NULL bytes to reach a fixed length of 14 bytes.
  5. This fixed-length password is divided into two halves of seven bytes each.
  6. Each half is converted into a DES key by taking seven bytes and transforming them into a bit stream with the most significant bit first; parity bits are inserted after every seven bits to create a complete 64-bit DES key.
  7. Each DES key encrypts the constant ASCII string “KGS!@#$%” using DES in ECB mode without padding.
  8. The two resulting ciphertext blocks of eight bytes each are concatenated to form the complete 16-byte LM hash.

Security weaknesses

The LM hash algorithm used in LAN Manager authentication is inherently weak and dates back to the mid-1980s when concerns about floppy disk viruses were prevalent. Although it relies on the well-established DES cipher, its design contains critical vulnerabilities that allow hashes to be cracked within seconds using rainbow tables or in minutes via brute-force techniques. Beginning with Windows NT, LM hashing was replaced by NTLM, which also exhibits susceptibility to similar attacks unless strong and unpredictable passwords are employed. NTLM remains in use for local account authentication except on domain controllers; starting with Windows Vista, LM hashes are no longer stored by default. In Active Directory environments, Kerberos is employed instead.

Major flaws in LAN Manager authentication include:

  1. Password length is limited to fourteen characters drawn from 95 printable ASCII characters.
  2. Passwords are case-insensitive since all letters are converted to uppercase before hashing, drastically reducing the effective password space.
  3. A fourteen-character password is split into two separate seven-character halves that are hashed independently; this division simplifies cracking because an attacker only needs to brute force two smaller segments instead of one long password.
  4. Modern graphics processing units (GPUs) can compute approximately forty billion LM hashes per second, enabling all possible seven-character passwords from the full character set to be cracked in less than thirty minutes; alphanumeric-only passwords can be broken within seconds.
  5. For passwords shorter than or equal to seven characters, the second half of the hash remains constant and easily recognizable.
  6. LM hashes lack salting during transmission, exposing them to man-in-the-middle and replay attacks such as pass-the-hash; this vulnerability facilitates efficient precomputed dictionary attacks using rainbow tables.

Exploitation tools like Ophcrack (introduced in 2003), RainbowCrack, Hashcat, L0phtCrack, and Cain leverage these weaknesses, rendering LM hash cracking both rapid and straightforward.

Workarounds

In response to vulnerabilities in LM encryption and authentication, Microsoft launched the NTLMv1 protocol in 1993 alongside Windows NT 3.1. This iteration enhanced hashing by incorporating Unicode compatibility and substituting the LM hash with NThash=MD4(UTF-16-LE(password)), thereby removing issues related to padding or truncation. Despite these improvements, it still depended on 56-bit DES encryption without salting, and Windows systems commonly accepted both LM and NTLM hashes by default, which undermined the security benefits. Furthermore, early password management tools imposed length limitations that hindered progress.

Although LAN Manager is now outdated and newer Windows editions utilize more robust protocols such as NTLMv2 or Kerberos, versions preceding Windows Vista/Windows Server 2008 activated LM hashing by default to maintain compatibility with older clients and NetBIOS-based applications. It has become standard security practice to disable LM and NTLMv1 protocols wherever they are unnecessary. Starting with Windows Vista/Server 2008, LM hashing is turned off by default but remains configurable through security policies for local or Active Directory accounts. Users can prevent LM hash creation by choosing passwords with a minimum length of fifteen characters. However, recent developments have exposed NTLM hashes to attacks that reduce their security to levels comparable to those of LM hashes in 1998.

Reasons for continued use of LM hash

The slow adoption of Microsoft's enhanced protocols by legacy third-party SMB implementations was largely due to the requirement for reverse engineering by open-source communities—Samba took five years before supporting NTLMv2, while JCIFS required ten years.

Availability of NTLM protocols replacing LM authentication
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 (October 25, 1998)
Windows 95 Not supported Directory services client (with Windows 2000 Server, 2000)
Windows 98 RTM Directory services client (with Windows 2000 Server, 2000)
Windows 2000 RTM (2000) RTM (2000)
Windows Me RTM (2000) Directory services client (with Windows 2000 Server, 2000)
Samba ? Version 3.0 (2003)
JCIFS Not supported Version 1.3.0 (2008)
IBM AIX (SMBFS) 5.3 (2004) Not supported as of v7.1

Many organizations have persisted in using LM hashing despite its straightforward deactivation through Active Directory, often due to inadequate patch management following initial support releases. Moreover, prior to Windows Vista, numerous unattended installations relied on DOS boot disks that necessitated LM hashing for compatibility with legacy LAN Manager networking features.

See also

External links