This chapter is from the book
This chapter is from the book
This chapter is from the book
User Authentication
Almost all Terminal Server implementations require that the users perform some form of authentication in order to verify that they are who they say they are. Exceptions to this rule would include kiosk-type implementations where anonymous users access a general-purpose Terminal Server session in order to utilize a specific application. Most corporate Windows environments utilize the familiar Windows logon dialog box (see Figure 16.8) to enforce use of a user ID/password combination for user authentication. While this is the most common form of authentication, it unfortunately is also typically the weakest and most vulnerable of the security layers.
)
Figure
16.8 The Windows Server 2003 logon window.
The reason for this weakness is not simply technical but also educational. In most organizations, the user community lacks understanding regarding the importance of adequate password "strength" and the potential consequences of a compromised user account. Password-cracking tools are readily available and can easily be used to discover weak passwords in an organization.
TIP
The term strength is often used to describe the relative complexity of a password and its resistance to cracking through either manual or automated means. Some common weak passwords include the following:
A blank password or no password at all.
Some variant of the word password.
A password based on the user's name, their spouse's name, or some other common dictionary word such as bird, tree, snow, monkey, dog, and so on.
A password based on a user's phone number, home address number, birthday, an so on.
Password-cracking tools attempt to exploit use of weak passwords and typically uÏtilize a combination of three cracking strategies to achieve their goal:
Dictionary attacks—Common words found in the dictionary are used to try to quickly match user passwords.
Targeted-word attacks—A customized dictionary of specific words is used to try to determine the user password. Custom dictionaries are usually created based on information gathered either through social engineering or other means of personal information acquisition and typically target a specific user or group of users.
Brute-force attacks—Every possible combination of characters is used to try to discern the password. In many cases the dictionary and brute-force attacks are integrated to try to find quick hits. With sufficient time, a brute-force attack will determine any password. Of course, the complexity and length of a password determine whether such an attack can discover a password in a realistically finite amount of time.
It is not difficult to see that these strategies would easily pick off passwords such as disney, porsche, or jennifer27, all of which are passwords I've encountered within large production Terminal Server environments.
A number of different password-cracking tools are readily available for most operating systems. A small sample of these include
LC5—The latest version of the famous L0phtCrack password auditing and recovery tool. Different variants of this product are available to be purchased, with the high-end product offering a number of different password-cracking techniques such as brute-force, dictionary attacks and pre-computed password tables (also known as rainbow tables). Trial versions used to be available for the product, but at the time of this writing, the latest version did not offer a trial version. The Website is http://www.atstake.com/products/lc/
Cain & Abel—A robust and powerful password recovery tool, Cain boasts an astounding array of features, including a number of different network packet filtering options. Best (or worst) of all, this tool is completely freeware. The product can be found at http://www.oxid.it/projects.html.
Sarca Rainbow Tables—An online Web site that allows you to paste LanManager and NT password hashes onto the site and submit them for cracking using their generated rainbow tables. The site only processes hashes once per day but can crack a large number of passwords. Limitations on the actual processing are discussed on the site. http://sarcaprj.wayreth.eu.org
Not only are such tools a threat on their own, but when used in combination can very easily crack even relatively complex passwords. Of course certain conditions must be met, namely the potential cracker must be able to access the encrypted passwords. In most cases administrative privileges are required to access this information, but certain exploits may make such information available without directly acquiring these rights. Just another reason for keeping up-to-date with the available security patches for your environment.
My reason for listing these tools here is purely to demonstrate how readily up-to-date password-cracking and acquisition tools are available. Listing them here does not imply that I endorse the use of these tools for anything other than testing the strength of the passwords in an environment. I recommend caution when looking to use any password-auditing tool, particularly in production.
Please understand the risks involved in such endeavors. Use common sense when downloading and testing any software that may be coming from a suspect source.
While it is obvious that a "strong" password will be much more difficult to crack than a "weak" one, the added complexity can be a formidable obstacle during early stages of implementation, with the primary issue being simply that it is more difficult for the end user to remember a new, stronger password. In nearly every situation where I have been party to introduction of complex password requirements, the end user community in general has commented that the new passwords are "far too confusing," and "not necessary" for their organization or department. Without the proper education, users are unclear as to why they must use a complex password and as such become easily frustrated if the simple tasking of logging on is delayed enough to impact their ability to work. Failure to successfully introduce and enforce strong-password requirements in most cases is a result of the system administrator's inability to adequately manage the initial flood of demands from users requesting password resets or unlocking of a locked-out account in a timely fashion.
NOTE
Microsoft has tried to stress to administrators the idea of teaching users the concept of a "passphrase" instead of simply a password. While many users can struggle with trying to come up with and remember a seven-character password, a common phrase such as "I really love to drink coffee" can be easier to remember, easier to type, and stronger than a typical seven-character password. In an environment that is enforcing complex passwords, one way to ease password creation is to develop a passphrase that can then be used to "build" the password.
For example, a common technique I've used is to create a passphrase such as "Todd loves to spend money on his sports car." I then delete all but the first letter of each word and substitute the word to with 2 and money with $. The result is the password Tl2s$ohsc, which is suitably complex and also very easy to remember. I talk more about enforcing strong passwords in the next section of this chapter.
Account Password Policies
Unfortunately, education alone rarely ensures that all users in your organization use only a strong password. Most users, given the opportunity, try to use as simple a password as possible and recycle this password (or minor variations) over and over, if periodic password changes are required. As a general rule, an administrator should never leave it solely up to the end user to ensure that a sufficiently strong password is being used.
As a complement to user education, an administrator should leverage the security features available in Windows 2000/2003 to help enforce strong user password requirements. Both Windows versions support the same six password policies shown in Figure 16.9. A subset of these policies is enabled by default in a Windows 2003 domain; unfortunately the same cannot be said for a Windows 2000 domain, where none of these policies is enabled by default.
To modify the default password requirements in a Windows domain, these settings must be defined within the Default Domain Policy group policy object (GPO), located at the root of the domain. For example, in my noisyriversoftware.com domain, this GPO is found under the Group Policy tab for the noisyriversoftware.com object. If you wish to define these password settings for local accounts on a member server or PC, a GPO containing these settings must be created and assigned to an OU that contains the computers you want to update.
WARNING
Many organizations make the mistake of assuming that only those accounts with administrative privileges require strong passwords and that "regular" user accounts are not really as much of a concern. This is a dangerous misconception, particularly in an environment where regular patch management is not being performed. Frequently exploits are discovered that make it possible for a regular user to elevate their privileges beyond what they have been assigned and to gain full administrative control. Because of this, password security really must be enforced for all users in your environment and not only for those users with administrative privileges.
)
Figure
16.9 Windows 2000/2003 account password policies.
The six policies shown in Figure 16.9 provide the following functionality:
Enforce password history—To counteract the tendency of users to reuse the same password (or small set of passwords) over and over, this policy ensures that a specific number of unique passwords are used before a user's oldest password can be reused. By default this option is set to the maximum of 24 passwords remembered in a Windows 2003 domain.
Maximum password age—The longer a user is allowed to retain the same password, the greater the chances that the account may be successfully cracked or accessed by someone who may already have the password to the account. Periodically forcing a user to change their password helps minimize these risks. A Windows 2003 domain has a maximum password age of 42 days, which most administrators find to be an optimal medium between frequent password change requirements and adequate password aging.
Minimum password age—Complimenting the maximum password age policy is the minimum password age policy. This policy defines the minimum number of days a user must use the same password before it can be changed. The main reason for this policy is to ensure that users do not attempt to quickly change their password multiple times in order to reuse a desired password, effectively circumventing the "Enforce password history" policy.
Minimum password length—An adequate password length is critical to ensuring that user passwords remain secure by minimizing the effectiveness of brute-force attacks. Each increase in the minimum password length by one character exponentially increases the number of possible password permutations. Using only the standard characters on the keyboard, users have 94 possible characters to choose from when selecting their password. These 94 characters are comprised of 52 alphabetical characters (uppercase and lowercase), 32 additional characters (#, $, *, @, etc.), and 10 numeric characters (0, 1, 2, 3, etc.). When the minimum password length is 7, the user can choose from 947 (approximately 64,000,000,000,000) possible different passwords.
Password must meet complexity requirements—Even with all these password requirements in place, education alone will not ensure that the end user consistently selects a strong password. Without some means of ensuring that a minimum level of strength is being used, the users are likely to pick the simplest password possible that complies with the policies in place.
A possible side effect of enforcing a lengthy password history is that users may start maintaining a paper record of their password to help them remember what they are currently using. The two most effective ways to counteract this are through the proper education of secure computing practices and the use of a suitably long maximum password age (described next) to allow the user time to learn the password before the system once again requires them to change it. My preference is to use the maximum value of 24 in all production Windows domains whenever possible.
Similar to enforcing a large password history, requiring users to change their passwords too often will likely result in at least some of the users keeping a paper record of their current password, often in an easily accessible location (taped to the monitor, under the keyboard, and so on). I highly recommend not setting the maximum password aging to zero (0) but instead using the default of 42 days.
Windows 2003 defaults to a minimum password age of one (1) day, meaning that a user can change their password only once per day. This policy does not prevent an administrator from resetting a user's password.
Of course, as the password length increases, so does the risk that a user will be unable to remember the password they are using. Windows 2003 defaults to a minimum length of seven characters, and I recommend that passwords use at least this many characters.
The "Password must meet complexity requirements" policy lets you enable your Windows environment to perform a complexity validation check whenever a user's password is changed. Here are the complexity requirements
Password must have a minimum length of six characters.
This requirement takes priority over the "Minimum password length" policy if the minimum length has been set to less than six characters.
The password must contain characters from at least three of the following categories:
-
Uppercase characters "A" through "Z."
-
Lowercase characters "a" through "z."
-
Numeric characters 0 through 9.
-
Non-alphanumeric symbols such as !, @, #, %, and so on.
The password cannot contain substrings of three or greater characters in length found in the user's full account name. When this requirement is validated, the user's full name is broken up into substrings using commas, periods, dashes, hyphens, underscores, number signs, and spaces as string delimiters. The password is then searched for substrings matching these tokens. If any matches are found, the password is rejected. Any substrings of three or fewer characters are ignored. For example, if a user has the name Steven Li Chan, it is broken into three substrings: "Steven", "Li", and "Chan". The name "Li" is dropped because it is less than three characters, while the other two tokens are used to search the password. If either "Steven" or "Chan" appears in the password, it is rejected. The searches are case insensitive, so "CHaN", "chan", and "ChaN" are all considered to be the same.
When a user's password is changed and it fails validation, a message similar to the one in Figure 16.10 appears. The Windows 2000 message differs slightly, providing a more verbose description of the password requirements. Invariably, when this policy is first implemented, users have a difficult time interpreting the password requirements. I've found that a separate description of the password requirements (including some password examples) made available to the user, either via an e-mail message or as a physical printout, can greatly ease transition pains associated with enforcement of complex passwords.
){kind=small}
Figure
16.10 A Windows Server 2003 complex password requirements message.
TIP
Password validation requirements are provided as part of the passfilt.dll system file. When a password change request is made, the Local Security Authority (LSA) module of the Windows subsystem calls the password filters provided in this DLL to validate the password requirements. While the password requirements supplied with the default passfilt.dll file cannot be modified, a custom passfilt.dll file could be created containing customized password requirements for your organization. Details of such an undertaking are beyond the scope of this book, but if you are interested, you can find more information on the Microsoft Developers Network (MSDN) Web site at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/strong_password_enforcement_and_passfilt_dll.asp
-
Store passwords using reversible encryption—In most situations, this policy should never be enabled because it forces Windows to store passwords in such a way that they can be decrypted. This is inherently much weaker than the standard method of one-way encryption and provides an attacker with an additional means of compromising one or more user accounts.
With proper use of these six security policies you can minimize the vulnerabilities traditionally found with ID/password user authentication.
Account Lockout Policies
In addition to enforcing use of strong passwords, another mechanism for increasing security of Windows user authentication is use of user account lockout policies. Essentially, these policies provide a means of temporarily disabling a user's account if a predefined number of unsuccessful user ID/password authentication attempts are performed within a given period of time. Figure 16.11 shows the three account lockout policies found in both Windows 2000 and Windows 2003. By default none of these options are enabled in either operating system.
)
Figure
16.11 Windows Server 2003 account lockout policies.
The three policies shown in Figure 16.11 provide the following functionality:
Account lockout duration—This policy determines the amount of time a user's account remains disabled until it is automatically re-enabled by the system. I typically recommend that the duration be set to zero (0) in order to minimize the number of brute-force or dictionary-based attempts that can be performed against a user account before an administrator's intervention is required. When set to zero, an account remains locked until manually unlocked by an administrator.
Account lockout threshold—The lockout threshold represents the number of incorrect password attempts allowed before a user's account is disabled. One factor influencing this value is the lockout duration you configured for your environment. If the duration is set to zero (0), the lockout threshold can typically be assigned a value of 10 to 15. In most situations a user is not likely to repeatedly try their password this many times within the account lockout reset interval (see the following point).
Reset account lockout counter after—This setting dictates the amount of time that must pass before the lockout counter is automatically reset to zero. A value of 30 minutes is usually appropriate for most environments.
The one thing to consider when setting the lockout duration to zero is that a user cannot log on until an administrator manually re-enables the account. To minimize the chances of a user legitimately locking themselves out, settings for the other two account lockout policies must be set accordingly, as discussed in the following points.
When first implementing account lockout policies in your organization, it is not unusual to see a high number of account lockouts occur, particularly when first implementing strong password requirements. It will likely take a few days before the issues balance out to an acceptable level. At this time you may need to make minor adjustments to your configuration to reach a mutually agreeable configuration for both users and administrators.
WARNING
An unfortunate downside that exists when lockout policies have been implemented is that a malicious user could exploit this configuration to purposely lockout user accounts, effectively performing a denial of service (DOS) attack on the environment. This is one of the reasons why the administrator's account cannot by default be locked out. While there is no sure-fire way to prevent this, limiting external access to the environment as much as possible will at least help to contain such a threat to within the confines of the internal network.