Securing Passwords

Securing Passwords

Historically, user passwords are the biggest security risk to networks. This risk includes the creation of passwords, the way users protects their passwords, how the operating system stores these passwords, and how the passwords are transmitted across the network.

Understanding Authentication

The operating system is responsible for securely storing and transmitting credentials (user names and passwords) for accounts. Windows 2000 and Windows XP support a variety of protocols to transmit credentials across the network to authenticate accounts, including user accounts, computer accounts, and service accounts. The operating system also stores credentials in a variety of formats.

When a user logs on to Windows NT, Windows 2000, or Windows XP by using the Windows Logon dialog box, several components work together to securely authenticate her credentials. Figure 3-4 shows the information flow of authentication.

Figure 3-4. Authentication in Windows NT, Windows 2000, and Windows XP

Windows NT, Windows 2000, and Windows XP support authentication using the LAN Manager (LM), NT LAN Manager (NTLM), and NT LAN Manager version 2 (NTLMv2) protocols. Windows 2000 and Windows XP use Kerberos v5 as the default authentication protocol. Because few networks use a single operating system version or applications that use the same authentication APIs, Windows NT, Windows 2000, and Windows XP support current and legacy authentication methods to preserve compatibility with downlevel operating systems.

LAN Manager

LAN Manager authentication is supported in Windows NT, Windows 2000, and Windows XP to support legacy applications. LM passwords are limited to 14 characters. With LM, passwords themselves are not stored by the operating system. Instead, the passwords are encrypted with the LAN Manager one-way function (OWF), which is formed by converting the password to uppercase characters, breaking the 14-character password into 7-character halves, adding padding for passwords with less than 14 characters, and encrypting a constant with the 7-character halves by using the DES encryption algorithm. This process is illustrated in Figure 3-5.

Figure 3-5. LM password storage

When a user authenticates a password by using the LM authentication protocol, the authentication is done with a simple challenge/response from the authenticating domain controller or computer. Figure 3-6 shows the process of authenticating an account by using LM.

Figure 3-6. LM authentication

In Figure 3-6, the client sends an authentication request to the logon server. The server returns a challenge, which is comprised of a random number, or nonce. The client then uses the LM password hash to encrypt the nonce by using the DES encryption algorithm. Next, the server decrypts the encrypted nonce from the client by using the LM password it has stored in the accounts database. If the nonce matches the nonce sent to the client, the client s credentials are validated.

By reducing the keyspace for letters to include only uppercase letters, limiting passwords to 14 characters, and separating passwords into 7-character pieces, you make LM password hashes especially vulnerable to brute force and dictionary attacks. Many tools available on the Internet can easily crack most LM password hashes given enough computer power and time. Windows 2000 Service Pack 2 adds functionality that enables you to remove LM password hashes from Active Directory or local computer SAM databases. The following table shows the registry key and value to add to the registry in order to remove LM password hashes. You can also add a custom registry modification to Windows 2000 security templates and deploy the change by using Group Policy.

Location	HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Type	DWORD
Key	NoLMHash
Default value	0
Recommended value	1 (removed LM password hashes)

You must implement this registry change on all domain controllers in the domain to fully prevent the creation of LM password hashes. Additionally, this change will not take place until users change their passwords the first time after the registry has been changed. You can also prevent the LM authentication protocol from being used by a Windows NT, Windows 2000, or Windows XP computer by setting the LM compatibility to a level greater than 0. We will discuss LM compatibility levels in further detail momentarily, when we examine NTLMv2.

NTLM

NT LAN Manager, also known as NTLM, first shipped with Windows NT and is an improvement over the LM authentication protocol. Unlike LM passwords, NTLM passwords are based on the Unicode character set, are case sensitive, and can be up to 128 characters long. As with LM, the operating system does not actually store the password; rather, it stores a representation of the password by using the NTLM OWF. The NTLM OWF is computed by using the MD4 hash function, which computes a 16-byte hash, or digest, of a variable-length string of text, which in this case is the user s password.

A hash function takes a variable-length binary input and produces a fixed-length binary output that is irreversible. No two binary inputs will produce the same binary output, and no two binary outputs will match the same binary inputs. Common hash functions include MD4, MD5, and SHA1.

Another difference between NTLM and LM is that NTLM passwords are not broken into smaller pieces before having their hash algorithm computed. NTLM uses the same challenge/response process for authentication as LM does. NTLM is the default authentication provider in Windows NT and Windows 2000 (when the Windows 2000 machine is not a member of an Active Directory domain).

NTLMv2

NTLMv2, the second version of the NTLM protocol, was first available in Windows NT 4.0 Service Pack 4 and is included in Windows 2000. NTLMv2 passwords follow the same rules as NTLM passwords; however, NTLMv2 uses a slightly different process to compute the password hash and a different process for authentication. NTLMv2 also requires that the clocks of clients and servers be within 30 minutes of each other.

NTLMv2 uses a keyspace for password-derived keys of 128 bits. This makes brute force attacks difficult. If both the client and the server support NTLMv2, enhanced session security is negotiated. This enhanced security provides separate keys for message integrity and confidentiality, provides client input into the challenge to prevent chosen plaintext attacks, and uses the HMAC-MD5 algorithm for message integrity checking. Because the datagram variant of NTLM does not have a negotiation step, use of otherwise negotiated options (such as NTLMv2 session security and 128-bit encryption for message confidentiality) must be configured. This next table lists the registry key for setting NTLM negotiation options:

Type	DWORD
Location	HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\
Key	NtlmMinServerSec
Default value	0x00000000

The following table lists the registry key for configuring the levels of NTLMv2 support:

Type	DWORD
Location	HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\
Key	NtlmMinClientSec
Default value	0x00000000

Table 3-5 lists the values for the client negotiation options just described.

Table 3-5. Values for Setting NTLMv2 Client Negotiation Options

Value	Description
0x00000010	Message integrity
0x00000020	Message confidentiality
0x00080000	NTLMv2 session security
0x20000000	128-bit encryption

You can combine multiple NTLMv2 options by performing a logical OR on the settings in Table 3-5.

Enable NTLMv2 by setting the LM compatibility level by using Group Policy. The six LM compatibility settings are described in Table 3-6.

Table 3-6. LM Compatibility Levels

Level	Description	Details
Level 0	Send LM and NTLM response and never use NTLMv2 session security.	Clients will use LM and NTLM authentication and never use NTLMv2 session security. Domain controllers will accept LM, NTLM, and NTLMv2 authentication.
Level 1	Use NTLMv2 session security if negotiated.	Clients will use LM and NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers will accept LM, NTLM, and NTLMv2 authentication.
Level 2	Send NTLM response only.	Clients will use only NTLM authentication and will use NTLMv2 session security if the server supports it. Domain controllers will accept LM, NTLM, and NTLMv2 authentication.
Level 3	Send NTLMv2 response only.	Clients will use NTLMv2 authentication and use NTLMv2 session security if the server supports it. Domain controllers will accept LM, NTLM, and NTLMv2 authentication.
Level 4	Domain controllers refuse LM responses.	Clients will use NTLM authentication and use NTLM 2 session security if the server supports it. Domain controllers will accept only NTLM and NTLMv2 authentication; they will refuse LM authentication.
Level 5	Domain controllers refuse LM and NTLM responses.	Clients use NTLMv2 authentication and use NTLMv2 session security if the server supports it. Domain controllers will accept only NTLMv2 authentication; they will refuse NTLM and LM authentication.

When setting LM compatibility levels on your network, you will need to ensure that the levels are consistently set on both clients and servers. Setting LM compatibility to Level 4 or higher on servers might cause authentication issues with some applications. The registry key for setting LM compatibility levels is shown in the following table. You can also set this option using Group Policy.

Type	DWORD
Location	HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Key	LMCompatibilityLevel
Default value	0

Setlmcompat.vbs is located in the Tools\Scripts folder on the CD included with this book. This tool will configure the LAN Manager compatibility level on a computer running Windows NT 4.0 or later operating systems.

Kerberos

The default authentication protocol in Windows 2000 and Windows XP is Kerberos v5. Windows operating systems prior to Windows 2000 do not support the use of Kerberos. The implementation of Kerberos in Windows 2000 is compliant with RFC 1510 and is interoperable with other Kerberos v5 realms that are RFC 1510 compliant. Kerberos provides the following benefits:

• Mutual authentication

  Kerberos enables the client to verify a server s identity, one server to verify the identity of another, and the client to verify its identity to the server.

• Secure transmission over the wire

  Kerberos messages are encrypted with a variety of encryption keys to ensure no one can tamper with the client s ticket or with other data in a Kerberos message. Furthermore, the actual password and any derivation of it can never be sent across the network when using Kerberos.

• Prevention of replay of authentication packets

  Kerberos minimizes the possibility of someone obtaining and reusing a Kerberos authentication packet by using timestamps as an authenticator. By default in Windows 2000, all clocks must be synchronized to within 5 minutes of each other for Kerberos authentication to function.

• Delegated authentication

  Windows services impersonate clients when accessing resources on their behalf. Kerberos includes a proxy mechanism that allows a service to impersonate its client when connecting to other services.

The following four components allow Kerberos v5 authentication between Windows 2000 clients and Windows 2000 domain controllers:

• Key distribution center (KDC)

  The network service that supplies both ticket-granting tickets (TGTs) and service tickets to users and computers on the network. The KDC manages the exchange of shared secrets between a user and a server when they authenticate with each other. The KDC contains two services: the Authentication Service and the Ticket Granting Service. The Authentication Service provides the initial authentication of the user on the network and provides the user with a TGT. Whenever users request access to a network service, they supply their TGT to the Ticket Granting Service. The Ticket Granting Service then provides the user with a service ticket for authentication with the target network service. In a Windows 2000 network, the KDC service runs on all Windows 2000 domain controllers.

• Ticket-granting ticket (TGT)

  Provided to users the first time they authenticate with the KDC. The TGT is a service ticket for the KDC. Whenever the user needs to request a service ticket for a network service, she presents the TGT to the KDC to validate that she has already authenticated with the network. For additional security, Windows 2000 verifies, by default, that the user account is still active every time a TGT is presented to the KDC. In other words, the KDC verifies that the account has not been disabled. If the account has been disabled, the KDC will not issue any new service tickets to the user.

• Service ticket

  Provided by a user whenever he connects to a service on the network. The user acquires the service ticket by presenting the TGT to the KDC and requesting a service ticket for the target network service. The service ticket contains the target server s copy of a session key and contains information about the user who is connecting. This information is used to verify that the user is authorized to access the desired network service by comparing the authentication information namely, the user s SID and his group SIDs against the DACL for the object that he is attempting to access. The service ticket is encrypted using the key that is shared between the KDC and the target server. This ensures that the target server is authenticated because only the target server can decrypt the session key.

• Referral ticket

  Issued anytime a user attempts to connect to a target server that is a member of a different domain. The referral ticket is actually a TGT to the domain where the resource is located. The referral ticket is encrypted using an interdomain key between the initial domain and the target domain that is exchanged as part of the establishment of transitive trust relationships.

All Kerberos authentication transactions will be composed of some combination of these three message exchanges:

• Authentication Service Exchange

  Used by the KDC to provide a user with a logon session key and a TGT for future service ticket requests. The Authentication Service Exchange is comprised of a Kerberos Authentication Service Request (KRB_AS_REQ) sent from the user to the KDC and a Kerberos Authentication Service Reply (KRB_AS_REP) returned by the KDC to the user.

• Ticket-Granting Service Exchange

  Used by the KDC to distribute service session keys and service tickets. The service ticket that is returned is encrypted using the master key shared by the KDC and the target server so that only the target server can decrypt the service ticket. A Ticket-Granting Service Exchange is comprised of a Kerberos Ticket-Granting Service Request (KRB_TGS_REQ) sent from the user to the KDC and a Kerberos Ticket-Granting Service Reply (KRB_TGS_REP) returned by the KDC to the user.

• Client/Server Authentication Exchange

  Used by a user when presenting a service ticket to a target service on the network. The message exchange is comprised of a Kerberos Application Request (KRB_AP_REQ) sent from the user to the server and a Kerberos Application Response (KRB_AP_REP) returned by the target server to the user.

To use the Client/Server Authentication Exchange, the user enters her login name, password, and domain in the Windows Logon dialog box. The client computer then locates a KDC by querying DNS server. Next, the user s computer sends a Kerberos Authentication Service Request (KRB_AS_REQ) to the domain controller. The user s account information and the current computer time are encoded by using the long-term key shared between the user s account and the KDC. Finally, the authentication service at the KDC authenticates the user, generates a TGT for her, and sends the TGT to her in a Kerberos Authentication Service Response (KRB_AS_REP) message.

When a user authenticates himself by using Kerberos, a series of packets are exchanged to complete the validation of his credentials. Figure 3-7 illustrates this process. In the figure, the user sends a Ticket-Granting Service Exchange Request (KRB_TGS_REQ) to the KDC to acquire a service ticket for his computer. The KRB_TGS_REQ contains an authenticator and the TGT that was issued to the user. The Ticket-Granting Service of the KDC checks the TGT and the authenticator. If both are valid, the Ticket-Granting Service generates a service ticket and sends it back to the user via a Ticket-Granting Service Response (KRB_TGS_REP). At the client computer, the service ticket is presented to the Local Security Authority, which will create an access token for the user. (We will discuss the Local Security Authority in a moment.) From then on, any process acting on behalf of the user can access the local machine s resources.

Figure 3-7. Initial Kerberos authentication

This sequence provides the user with the proper TGT. If the user is using a Windows 2000 based computer, he must now acquire a service ticket for that computer. The following steps and Figure 3-8 explain how the service ticket for the computer is acquired.

1. The user sends a Ticket-Granting Service Request (KRB_TGS_REQ) to the KDC to acquire a service ticket for the target computer. The KRB_TGS_REQ includes the TGT and an authenticator.

2. The Ticket-Granting Service of the KDC checks the authenticator and the TGT, generates a new service ticket, and sends it back to the user via a Kerberos Ticket-Granting Service Response (KRB_TGS_REP). The service ticket is encrypted by using the target service s long-term key, which is known only by the KDC and the target service.

3. The user sends the service ticket and an authenticator to the target server by using a Kerberos Application Request (KRB_AP_REQ).

4. The target server verifies the ticket with the authenticator, decrypts the session key by using the master key that is shared with the KDC, and sends back an authenticator to the user in a Kerberos Application Response (KRB_AP_REP). This provides mutual authentication of the user and server.

   

   Figure 3-8. Obtaining a Kerberos session ticket

You can view the Kerberos tickets that have been issued to your user and computer accounts by using either Klist.exe, a command-line tool, or Kerbtray.exe, a GUI tool. Both of these utilities not only display the tickets, but also all their properties and expiration dates.

After initially authenticated with the network, the user must authenticate with other computers as he accesses resources on them. Every time the user connects to a resource or service on a remote computer, he has to perform a network authentication.

Storing Secrets in Windows

In addition to storing passwords in Active Directory or SAM databases, Windows NT, Windows 2000, and Windows XP store passwords and other secrets in other locations for a variety of purposes.

LSA Secrets

The Local Security Authority (LSA) maintains information about all aspects of local operating system security. The LSA performs the following tasks:

• Authenticating users

• Managing local security policy

• Managing audit policy and settings

• Generating access tokens

In addition, the LSA stores information secretly used by the operating system, known as LSA secrets. LSA secrets include items such as persistently stored RAS information; trust relationship passwords; user names, passwords, and account names; and passwords for services that run under a user account context. LSA secrets can be revealed locally by accounts with the Debug Programs user right. Consequently, you should be careful about the information applications have stored in LSA secrets. Attackers who physically compromise the computer can easily gain access to the information stored as LSA secrets if no other precautions are taken, such as using the System Key (Syskey.exe).

Writing Secure Code, Second Edition by Michael Howard and David LeBlanc (Microsoft Press, 2003) contains detailed information and code sample of how to retrieve LSA secrets. Additionally, you can view most LSA secrets by using LSADUMP2.exe from BindView. The tool is available at http://razor.bindview.com/tools/.

Using System Key (Syskey.exe)

The System Key utility was first available in Windows NT 4.0 Service Pack 2 and is enabled by default in Windows 2000 and Windows XP. You can configure the System Key utility by typing syskey at the command prompt. Only members of the Administrators group can run Syskey.exe to initialize or change the System Key. The System Key is the master key used to protect the password encryption key; therefore, protection of the System Key is a critical system security operation. You have three options for managing the System Key:

• Level 1

  Uses a machine-generated random key as the System Key and stores the key on the local system. Because the key is stored on the operating system, it allows for unattended system restart. By default, System Key Level 1 is enabled on all computers running Windows 2000 and Windows XP.

• Level 2

  Uses a machine-generated random key and stores the key on a floppy disk. The floppy disk with the System Key is required for the system to start before the system is available for users to log on. Because the System Key is stored on the floppy disk, the operating system is vulnerable to destruction of the floppy disk, which would render the operating system unable to boot.

• Level 3

  Uses a password chosen by the administrator to derive the System Key. The operating system will prompt for the System Key password when the system begins the initial startup sequence, before the system is available for users to log on. The System Key password is not stored anywhere on the system; instead, an MD5 hash of the password is used as the master key to protect the password encryption key. If the password is forgotten, the operating system will be rendered unable to boot.

Setting the System Key to Level 2 or Level 3 will greatly increase the security of the operating system and the secrets it contains (such as contents of the SAM database and LSA secrets) in the event an attacker physically compromises the computer. However, the Level 2 and Level 3 settings can be difficult to manage because you cannot recover forgotten or lost keys. If a key is lost, the computer will not be able to boot. You should develop a secure method of archiving System Keys if you decide to implement System Key Level 2 or Level 3 on your network.

DPAPI

The Data Protection API (DPAPI) enables secrets to be stored securely by applications by using a key derived from the user s password. The encryption of secrets can only be done locally, unless unencrypted roaming profiles are used. If the user s password is reset, the key used for DPAPI will be lost unless it is archived. DPAPI is available only on Windows 2000 and Windows XP.

Cached Credentials

By default, Windows NT, Windows 2000, and Windows XP cache the credentials of domain accounts used to log on to the network at the local computer. The credentials include the user s user name, password, and domain. Rather than storing the actual credential information, the information is stored in an irreversibly encrypted form and on the local computer. After a user has successfully logged on to the network from the computer once, he can use his domain credentials, even if the computer is not attached to the network or if no domain controllers are available. This functionality is critical to laptop users and users in branch offices without local domain controllers. You can control the number of credentials stored on a computer at any time by setting the registry key shown in this table:

Location	HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\Current Version\Winlogon\
Key	CachedLogonsCount
Type	REG_SZ
Default value	10
Recommended value	0 50, depending on your security needs

In high security networks, you might want to set the number of cached credentials to 0. This setting requires all users of the computer to have their domain account credentials validated by a domain controller. This prevents a user who has been terminated from disconnecting her computer from the network, logging on by using cached credentials, and destroying information. When you implement this setting, laptop users can log on only when connected to the network, greatly limiting their mobility.

Credential Manager

Windows XP introduced a new method of managing credentials as well as the credentials of a user who is logged on. This functionality is provided by the Credential Manager, labeled Stored User Names And Passwords in the Windows XP user interface. The Credential Manager dynamically and manually creates credential sets (a user name and password) for resources that are available in the user interface and from the command line. You can manage the following types of credentials with the Credential Manager:

• User names and passwords

• X.509 certificates, including smart cards

• Passport accounts