Analyzing Account and Password Security Requirements

---

Network accounts are used to give users access to the data that is stored on the various network resources. Should an attacker be able to take over an account, they would be able to perform any tasks that the user could perform. In addition, an attacker could simply break the password that is associated with an account, and would be able to perform the operations that are assigned to it.

In the following section, you will learn how to analyze accounts and passwords and recognize the potential risks to them. You will be able to list the common vulnerabilities of varying types of accounts and understand the requirements of each type of account based on its role and the type of access that it will require.

There are three basic types of accounts:

External users Users that are outside of your organization, such as anonymous Internet users, users from a business partner, or even authenticated Internet users.

Internal users Users that are employees, consultants, temporary workers, and so on who work directly for your company. These users typically have physical access to the network.

Administrative Employees, consultants, and services with administrative permissions assigned to the accounts that they use.

Obviously, different types of accounts are going to have different security requirements. In the following section, you will learn how to identify the requirements of the different types of accounts.

Identifying Account Requirements

User accounts are used to determine what actions a particular user can perform. That being said, different types of accounts will require different levels of security. Each account type has an escalating level of trust and access to the system:

• External users have very limited access; it is good practice to consider that external users are potential attackers and lock them down accordingly. These accounts should have only the permissions that they require and no more because they are the accounts that are most likely to be exploited.

• Internal users have a higher level of access to the organization’s resources because they typically represent employees with access to the organizational assets. Although it may be tempting to treat internal users as if they were attackers and prevent them from having access to everything, that usually has a significant impact on the productivity of the organization.

• Administrative accounts represent an ideal target to the would-be attacker because they have advanced rights on the system. An administrative account can be used to create other accounts or to run an application service and therefore must be as secure as possible.

Accounts receive their access rights from several different sources:

User rights User rights are the rights that are assigned to users. They allow the user to perform specific actions, such as logging on locally or as a service. Figure 4.3 shows the user rights assignments portion of the domain policy snap-in.

Figure 4.3: User Rights Assignment

Permissions Permissions are assigned using discretionary access control lists (DACLs) and are assigned for resources in Active Directory and NTFS. DACLS are made up of access control entries (ACEs) that specify the permissions on the identified object.

Note

ACEs are covered in more detail in Chapter 5.

Account scope The account scope determines where the account has authority. In a Windows network, there are two types of accounts: local accounts and domain accounts. Local accounts can be assigned permissions only on the computer that contains them, while domain accounts can be assigned permissions to any resource within the domain or a domain with a trust relationship with the containing domain.

Group membership Windows security groups allow you to assign permissions to a large number of users at a single time. This facilitates a consistent assignment of permissions to several similar users. Using groups to assign permissions makes the management and auditing of users more efficient. There are several types of groups within an Active Directory forest. Table 4.3 shows the different groups and what can be a member of each of the group types.

Table 4.2: Windows Group Types

Group Type	Membership	Scope
Universal	Native mode: Accounts, Global groups, other Universal groups.	Forest
	Mixed mode: Not Available.
Global	Native mode: Accounts or Global groups from same domain.	Domain
	Mixed mode: Accounts from same domain.
Domain Local	Native mode: Accounts, Global groups, and Universal groups from any domain, as well as other Domain Local groups from the same domain.	Domain
	Mixed mode: Accounts and Global groups from any domain.

The recommended practice for assigning permissions using groups in Windows networks is to follow the practice of AG(G)DLP. The following explains this process:

1. Place (A)ccounts in (G)lobal groups.

2. Optionally, nest (G)lobal groups.

3. Place the Global groups in (D)omain (L)ocal groups.

4. Assign (P)ermissions for the resource to the Domain Local group.

The acronym AG(G)DLP is a great way to remember this process. However, the last task you should perform is placing the Global groups in the Domain Local groups. You do this task last so that an account can’t use a permission until all of the permissions have been assigned.

Note

Universal groups are covered in detail in Chapter 5.

There are several techniques that you can employ to minimize your exposure to an attack on an account. The best thing that you can do is to not give an account any more authority than it requires. This concept is called the Principle of Least Privilege (PoLP). It states that an account should have the minimum permissions required to accomplish a task. User accounts should be granted only the privileges required to perform their job, service accounts should be granted only the privileges required to run the service, and only one service account should be granted per network service. You should have one service account that is used to run all SQL Server services across the domain and another service account for your Exchange Server services, and so on. Administrative accounts should be used only when administrative permissions are required to perform a task.

People who are in the role of a network administrator should have more than one account; one of them should be a typical user account with only the permissions of a normal user. The normal account should be the account that the administrator uses to log on to the system, check their e-mail, browse the Internet, and so on. In addition to the normal user account, the administrator should have an account with administrative permissions that is only used in conjunction with the runas command to run only those programs that require administrative level permissions.

Note

The runas command does not work with smart cards. The administrator would be required to log off as the normal user and log on using the smart card with an administrative account. Once the administrator performs the administrative tasks, they would log off the administrative account and log back on as the normal user.

In the “Analyzing Accounts” Design Scenario, you will be analyzing the security requirements of accounts in the given scenarios.

There are several vulnerable aspects of accounts that, when exploited, provide an attacker the access they are looking for. Passwords, as you might have guessed, represent a common target for an attacker. There are several password-specific issues that can be exploited to allow an attacker to hijack an account. As previously mentioned, a weak password is susceptible to brute force or dictionary attacks and can be easily broken. Many users use the same password for multiple resources, which usually have different levels of authentication security requirements. If one of the systems is compromised, the account can be hacked on multiple systems.

Take, for instance, a PIN for an ATM card, which operates like a password. Many users use the same PIN on several credit cards accounts, bank accounts, voicemail accounts, and so on. In this scenario, if an attacker can compromise one of the systems and learn the PIN, all of the systems are compromised.

Design Scenario: Analyzing Accounts

Scenario 1

Your network is running a SQL Server 2000 database that requires access to remote file shares stored on other computers in the domain. The service account that runs this service is currently configured as LocalSystem.

1. Question: What should you do to configure the SQL Server Service account to be able to access the remote file share while maintaining a highly secure environment? Answer: You should create a domain user account that has only the permissions required to execute the required tasks of SQL Server. It must be added to the ACL of the directory that contains the SQL Server data files and all other file system resources that the service will need to access. The SQL Service account would need to be given explicit user rights, such as the Login As A Service right on the server(s) running SQL Server. The account would also need the necessary ACEs to the Windows Registry ACLs for the keys that SQL Server needs to access. The reason for the domain account is because the service will need to access shares on remote servers and thus must authenticate over the network. If the SQL Server machine does not need to connect over the network to other servers, you should use a local user account, not an administrator or the LocalSystem account.

Scenario 2

You are the network administrator for an organization that has a main office in Pompano Beach, Florida. There are satellite offices in West Palm Beach and Miami that you must manage. You need to be able to manage all of the servers in your network no matter which location you are physically connected to. You’ve installed the Windows administration tools on your workstation (AdminPak.msi) to enable remote administration and your account is a member of the Domain Administrators group.

1. Question: What should you do to further secure your remote administration by protecting both the servers and the network as a whole? Answer: You should create a second account that you use to log on and access the non-administrati ve software (for example, Outlook, Internet Explorer, and any other applications that doesn’t require administrati ve permissions in order to function). You can then use that account to log on to the various sites and use the runas command when you need to launch any of the Active Directory administrative tools.

Another target for an attacker is an account that is assigned excessive privileges. This is obviously why the PoLP is so important. Users who have local administrator privileges or services that run as an administrator on a machine are examples of this vulnerability. SQL Server’s service account, in many cases, does not need to be a member of the local Administrators group. If the account is given elevated privileges, it can be exploited from within SQL Server as well as from within the application that uses SQL Server.

When it comes to determining the risks to accounts, you will need to evaluate the cost of the vulnerability to your organization and the cost to alleviate it. You may find that there is more than one solution to any given problem. Determining the most effective solution will be your goal. In a business environment, the effectiveness of the solution will probably be determined by how much money you can save. One of the most important things for management to keep in mind is return on investment (ROI).

With these vulnerabilities in mind, you need to know how to analyze a situation and determine the best way to deal with it. In the “Analyzing Account Risks by Cost Analysis” Design Scenario, you will evaluate a situation and determine the best solution.

In the next section, you will see some of the different techniques that you can employ to increase the security of these account vulnerabilities.

Designing Password Policies

In order to better secure passwords, you’ll need to know how the passwords are stored for each account. Kerberos passwords are stored in Active Directory as part of the user’s long-term key. NTLM passwords are stored as an MD4 hash value. LAN Manager passwords are case insensitive, and long passwords (up to 14 characters) are split into 7-character chunks and are then used to encrypt a constant value using the Data Encryption Standard (DES). The constant value is then stored. Service account passwords are stored persistently in cleartext as a Local Security Authority (LSA) account, while cached logon credentials are not stored persistently at all.

If attackers can gain physical access to a computer, they would be able to extract the NTLM and LAN Manager passwords from the Security Accounts Manager (SAM) database and then attack the hashes with well-known brute force and dictionary password tools. To prevent this type of breach, remove the LAN Manager password hashes from the computer and use strong passwords. You can use Group Policy to implement these policies, including the NoLMHash policy. The NoLMHash policy will disable the storage of LM hashes of a user’s password in the local computer’s SAM database or in a Windows Server 2003 Active Directory environment. To configure the Group Policy method, complete the following steps:

1. In Group Policy, expand Computer Configuration Windows Settings Security Settings Local Policies and click Security Options.

2. Double-click Network Security: Do Not Store LAN Manager Hash Value On Next Password Change.

3. Click Enabled, and then click OK.

On a single machine you can enforce this policy by following the preceding instructions but using the Local Security Policy MMC snap-in under Administrative Tools. You can also prevent the LM hash by requiring passwords that are longer than 14 characters or using certain Alt characters in your password.

Note

For more information on LM hash storage and techniques for removing LM hash storage, see Microsoft Knowledge Base article 299656 on the Microsoft support website.

Design Scenario: Analyzing Account Risks by Cost Analysis

It has been determined that weak passwords are affecting the overall security of your organization. The organization has estimated that, for each incident in which an attacker is able to guess the password that a particular account uses, it costs approximately $12,000. This cost includes all of the resources that are used in determining an incident has occurred and reacting to it. Your organization has also estimated that this type of attack occurs about eight times per year.

Your computer security incident response team has proposed three separate solutions, and you must determine which solution is the most appropriate given all of the information involved:

Solution 1 A security policy will be created and applied to all accounts in the organization. The policy will require complex passwords as defined by a custom filter that guarantees that strong passwords are the only type that are accepted. The help desk determines that it will cost the organization about $2,000 to implement this solution and that it will reduce the number of compromised passwords by 25 percent.

Solution 2 Solution 1 will be used, and in addition, all users and administrators will attend mandatory password training to assure that there are fewer calls to the help desk and that all users affected by an attack will understand what types of passwords are expected when they must select a new one. Password auditing will also take place on random samples of users to make sure that passwords are not easily located. The IT staff estimates that the total cost of this solution is $10,000 and that it would reduce the number of password-related security incidents by 50 percent.

Solution 3 Solution 1 will be used, and in addition, you will require that all users reset their passwords every 25 days. The help desk estimates that this will increase the support calls for password issues by 50 percent, cost $50,000 more per year for increased staff, and reduce the number of password-related incidents by 75 percent.

1. Question: Which is the best solution? Answer: With no solution in place, the org anization spends approximately $96,000 correcting the problem. Solution 1 will add $2,000 to the cost of the correcting the problem but will decrease the quantity of incidents to appro ximately six per year, which would cost $72,000. Solution 1 mak es the cost of the incidents $74,000 per year. Solution 2 will add $10,000 to the cost of implementation and will decrease the quantity of password-related security incidents to appro ximately four per year. Solution 2 reduces the cost of the password security incidents to $58,000 per year. Solution 3 adds $50,000 to the cost of the solution and reduces the incidents to two per year, which mak es the total cost of related incidents $64,000 per year. Based on cost, Solution 2 is the best answer in this situation.

Windows 2000 and above allow for policies to be set to require strong passwords. The options that are exposed using these policies are as follow:

Maximum Password Age The value you set for the Maximum Password Age policy represents the number of days that a password is valid until the user is required to change it. All passwords can be broken given enough time and the correct tool. With that in mind, one of your goals should be to require passwords that are complex and complicated enough so that they will take more time to break than the maximum password age. For example, if you suspect that a user’s password can be broken in 40 to 60 days, then the maximum password age should be less than the minimum amount of time that the password could be broken. For example, you could set the Maximum Password Age policy to 30 or 35 and feel confident that it won’t be broken before it must be changed.

Enforce Password History The value you set for the Enforce Password History policy is the number of unique passwords remembered by the system for the specified account. These passwords cannot be reused, so users will not be able to reuse a password that they have used previously.

Minimum Password Age The Minimum Password Age policy determines the number of days that a password must be used prior to it being changed. The default value for this option is zero. If Maximum Password Age is set to 30 and Enforce Password History is set to 12, the policy’s goal is to prevent a password from being used again for a year. Many users simply change their password 13 times as soon as it expires, allowing them to keep the original password. The Minimum Password policy prevents a user from circumventing the purpose of the Maximum Password Age and Enforce Password History policies by requiring that a new password must be in place for specified period of time before it can be changed.

Minimum Password Length The Minimum Password Length policy determines the minimum number of characters that must be used for a password. The default value is zero. Remember that if this value is greater than 14, the LM hashes will not be stored locally.

Passwords Must Meet Complexity Requirements The Passwords Must Meet Complexity Requirements policy requires passwords that do not contain the user’s name or login name, are at least six characters long, and contains characters from three of the following four groups:

• Uppercase letters

• Lowercase letters

• Numbers

• Special, non alphanumeric characters such as " < * & > ? / ; - _ = | \ . , ` ~ ^ % $ # @ !

Store Passwords Using Reversible Encryption Enabling the Store Passwords Using Reversible Encryption policy provides support for applications that use protocols that require knowledge of the user's password for authentication purposes. Enabling this policy is essentially the same as storing cleartext versions of the passwords. Because of this weakness, this policy should not be enabled unless the specific application’s requirements are of greater importance than the need to protect the integrity of the passwords.

This policy must be enabled if you are using Digest Authentication in Internet Information Services (IIS) or Challenge-Handshake Authentication Protocol (CHAP) authentication through remote access or Internet Authentication Service (IAS).

Note

Remote access is covered in Chapter 3 and IIS is covered in Chapter 7.

Account Lockout The Account Lockout policy disables an account when the number of failed authentication attempts exceeds a threshold. This policy can increase the number of help desk calls and wind up costing your organization money. For this reason, complex passwords and good auditing should be used to recognize a brute force attack on an account. The account lockout policy consists of three elements:

• Account Lockout Duration The Account Lockout Duration policy sets the number of minutes that an account will be locked before it is automatically unlocked. Many environments set this for a short amount of time. The time period is usually in place to minimize calls to the help desk by allowing the user to simply wait and try again after the lockout time period has passed. Obviously this would slow down a brute force attack because the attacker would be able to attempt only a set number of passwords before the account would be locked.

• Account Lockout Threshold The Account Lockout Threshold policy sets the number of invalid attempts that can occur before the account is locked. Many environments prefer to set this at 3, which is typically enough to allow a user to realize that they left their Caps Lock key on and still prevent a brute force program from testing a large number of passwords.

• Reset Account Lockout After The Reset Account Lockout After option sets the duration, in minutes, from an invalid logon attempt until the count resets itself back to zero.

The combination of these three account policy options, if used in concert, will minimize the attack surface of many brute force programs. Assuming Account Lockout Duration is set to 30 minutes, Account Lockout Threshold is set to 5, and Reset Account Lockout After is set to 15 minutes, an attacker would be able to attempt only 10 passwords per hour as opposed to many thousand per minute if no lockout policy is configured.

Tip

To better respond to potential attacks, you should make sure auditing is configured and evaluated on a regular basis.

In the “Analyzing and Securing Accounts with Account Policies” Design Scenario, you will analyze a scenario and use account policies to configure the accounts for the network in the scenario.

Account Logon Hours

A useful account setting that you can and should implement is setting valid logon hours. This feature exists in most network operating systems, including Windows Server 2003. The setting is configured using the account’s properties dialog box from the Active Directory Users And Computers MMC. It allows an administrator to specify when a user is allowed to access the network.

Suppose, for example, that a company has an employee whose job it is to take customer orders over the phone and enter them into an order application during business hours. There should be no reason for this user to be able to log on to the network outside of business hours (since he shouldn’t be on the phone).

Design Scenario: Analyzing and Securing Accounts with Account Policies

You are the administrator of a small network that does business with the government. Because of the partnership with the government, the security that must be in place must meet certain regulations. The regulations require that all accounts with access to sensitive data have complex passwords.

You have agreed to enforce a strong password policy on the users who have access to the government-related resources. You need to take the necessary precautions to prevent a brute force password cracking utility from attempting several password combinations to authenticate as a valid user.

1. Question: As the administrator of this network, you must configure account policies for the user accounts. Which of the following policies should you enable or define a value for?

   • Passwords Must Meet Complexity Requirements

   • Maximum Password Age

   • Enforce Password History

   • Account Lockout Duration

   • Account Lockout Threshold

   • Reset Account Lockout Counter After

   • Store Passwords Using Reversible Encryption

Answer: To enforce a strong password policy, you should enable the Passwords Must Meet Complexity Requirements option. To prevent an attacker from hijacking accounts, you should configure the accounts to be locked out after a set number of invalid logon attempts by enabling and setting a value for the Account Lockout Threshold policy. To facilitate this requirement, you’ll need to specify the time span that the account will be locked out, using the Account Lockout Duration policy.

---