The network. When a user connects to a resource across the network or uses a domain account to log on to a workstation, NT uses a challenge/response technique to authenticate the user. The workstation doesn't send the user's password or the password's hash across the network. Instead, the server the user is trying to connect to sends a string of bytes to the workstation as a challenge. The client uses NT's one-way encryption function to derive a hash from the password the user enters. Then, the client
encrypts the server's challenge with this password hash. The client sends the operation's result to the server as its response. The server performs the same operation using that user's password hash from the SAM. If the operation's result matches the client's response, the server authenticates the connection.
This challenge/response protocol prevents intruders connected to the network from sniffing clear passwords during authentication. However, readsmb, a program that comes with L0phtCrack 2.0, can derive users' passwords from the challenges and responses that pass across most NT networks. I recently started readsmb in a command prompt window, then I ran a NET USE command in another window to connect to a shared directory on another computer. Readsmb immediately output my username and challenge/response, as Screen 2 shows. I redirected the readsmb output to a file, then used L0phtCrack to derive the password from the hash.
By default, NT LAN Manager (LM) authentication uses both the NT hashing algorithm and the weaker LM hashing algorithm to encrypt challenge/ response sessions. The LM algorithm is weaker for three reasons. First, LM passwords are not case-sensitive. NT converts all passwords to uppercase before using the LM algorithm to hash them. Second, LM hashes can't be longer than seven bytes, so NT divides passwords that are longer than seven bytes into two segments before LM encryption. This division produces two passwords that are shorter and easier to crack than the original password. Third, LM hashing uses the Data Encryption Standard (DES) encryption formula, which is weak by today's standards. NT uses the stronger RSA MD4 encryption formula.
You must use the LM protocol for authentication if you want to connect resources on LAN Manager servers or Windows 98, Win95, or Windows 3.11 systems to your network or support these OSs' clients. (For a more detailed discussion about password hashing and NT's challenge/response technique, see Alan Ramsbottom's NT cryptography FAQ at http://www.ntbugtraq.com.)
If you have many NT clients and servers, the lm-fix hotfix can help protect at least some of your network's authentication requests. Lm-fix is not currently available because of compatibility problems with distributed component object model (DCOM), but Microsoft will probably release a new version of the hotfix soon. (For more information about Microsoft's removal of lm-fix from its Web site, see the sidebar, "Lm-fix: Now You See It, Now You Don't," page 132). Lm-fix adds the LMCompatibilityLevel value to the Registry. LMCompatibilityLevel lets you specify one of the following levels of authentication: level 0, which uses both LM and NT authentication; level 1, which uses only NT hashing unless a server requests LM authentication; and level 2, which never uses LM authentication.
Level 1 reduces but doesn't eliminate a system's vulnerability to man-in-the-middle attacks. A rogue computer can intercept a connection request over a level 1 network and request that the connecting client send it LM authentication. Enabling Server Message Block (SMB) signing might provide protection from this type of attackSMB places a digital signature that clients and servers use to authenticate messages from each other on each message blockbut OSs that don't recognize SMB signing won't be able to communicate with your NT systems if you require signing. (For more information about SMB signing, see Sean Daily, "NT Server Security Checklist, Part 2," page 135; the sidebar "SMB Signing," August 1997; and Microsoft Support Online article Q161372, "How to Enable SMB Signing in Windows NT," at http://support.microsoft.com/support/kb/articles/q161/3/72.asp.)
Level 2 is your most secure connection request option, but it can connect only resources on NT systems. Non-NT clients can't use level 2 security because they're not capable of NT authentication.
To implement lm-fix, load the hotfix on all your network's computers and set the LMCompatibilityLevel value on each computer. If your site includes Win95 systems, you must rely on physical security on LANs and encryption of WAN links to prevent hackers from sniffing the Win95 clients' connection requests.
If you must send LM hashes across the network, most security experts recommend using either 7-character or 14-character passwords. LM hashing of 8-character to 13-character passwords yields weaker second hashes, which hackers can use to try to guess the first hash before they crack it.
Cached credentials. The final place that NT stores password hashes is in a machine's cached credentials. By default, NT caches logon credentials from the past 10 successful logons. NT uses this cache to authenticate users locally when the network is down and no domain controller is available. Without this feature, you can't log on to a computer when the network is unavailable unless you have a local user account on that machine. Credential caching produces another copy of password hashes that hackers can find, and caches on machines that an administrator has recently logged on to contain that administrator's credentials.
Tools such as L0phtCrack do not currently scavenge passwords from machines' credentials cache, but they might soon. Syskey doesn't appear to encrypt this portion of the Registry. (Microsoft documentation doesn't make clear whether Syskey encrypts these hashes.) You need to disable caching on all your machines to protect your network. Set the CachedLogonsCount value in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon Registry key to REG_SZ 0. (Don't make this change using REG_DWORD. For more information about credential caching, see Sean Daily, "NT Server Security Checklist, Part 2," page 135 and Microsoft Support Online article Q172931, "Cached Logon Information," at http://support.microsoft.com/support/kb/articles/q172/9/31.asp.)
Register
