Harden Your Windows Network with Strong Passwords

Never before in the history of computing has security been of as much concern as it is today. It seems odd, then, that the basic mechanisms we use to guard against unauthorized access to networks, and more specifically the systems hosted on them, have been around since the dawn of electronic computing.

In this, the first of a three part look at increasing authentication security on your Windows Server 2003 based Active Directory environment, we'll look at how you can use the built in authentication mechanism – passwords – with maximum effect. We'll continue this discussion in a second, before moving on in part three to look at what's involved in implementing more advanced authentication mechanisms like smartcards and biometrics.

Using What You Have Already Got - Passwords
Although Hollywood movie directors would have us believe that any password can be cracked in less than 20 seconds by a tenth grade computer club member, the reality is that passwords, or more accurately passphrases, still offer enough protection for the majority of networks. That said, the difference in security strength between a simple password with no regulatory system to back it up and a complex password with fully configured management policies and account lockout systems, is huge. Fortunately, Windows Server 2003 provides all of tools needed to implement these policies. If you haven't already configured them, that's the first step toward a more secure authentication system.

Password Policy
The Password Policy defines how the system monitors and controls password usage. It provides a variety of options to make sure that users are using strong passwords, changing them frequently, and not reusing them too often. The Password policy for the domain is configured through the Domain Security Policy, which can be accessed directly from the Administrative Tools menu on a Windows Server 2003 system. It should be noted that the policy can also be configured from the Default Domain Controller Security Policy, so you'll need to understand Group Policy inheritance in order to implement it effectively.

You can see the Password Policy node of the Default Domain Security Policy in Figure 1. This screenshot shows the settings from a Windows Server 2003 system immediately following its promotion to a domain controller.

Figure 1. (Click for a larger image)

As you can see, the default settings require that users provide passwords of no less than seven characters, and that those passwords must be changed every 42 days. The system remembers the last 24 passwords that the user provided, preventing the user from cycling through the same small number of passwords. The minimum password age setting of 1 means that the user must wait at least one day before changing their password again. This, in concert with the Password History setting, prevents users from continually changing their password back to the same one that they were using.

With 'complexity requirements' turned on, passwords that users provide must meet certain criteria. The password cannot contain all or part of the users account name, must be at least six characters in length, and must contain at least three of the following criteria: upper or lower case characters, numbers, or special characters like ! or #.

You can take the password complexity requirements even further by creating your own password filters, but even with the default complexity requirements, users will have to provide passwords that are considered very strong. Any password that combines different characters and characteristics makes many traditional password cracking techniques largely ineffective.

The only other setting in the Password Policy that is worthy of special mention is the Store Passwords Using Reversible Encryption option. This is one that should be left disabled unless there is a very specific (and good) reason to do so. Enabling this option allows other applications, for example a Web-based inventory system, to access the user's password for authentication purposes. Sounds great, but if an external application can access the users password, it's not a huge leap to believe that other, less legitimate uses could also be made of this capability.

So what makes a strong password policy?

While there is no hard or fast answer to that question, the default settings provided on Windows Server 2003 are a good start. A minimum password length of seven characters is considered strong enough for most environments, but upping that minimum to eight provides even more security. The number of available combinations for a password goes up exponentially when an extra character is added, so eight characters is significantly more secure than seven.

Allowing 42 days between password changes might be a little on the long side - 28 might be a more prudent figure. Having a password expiration limit of 30 days might seem like a strong choice, but that would mean that every so often passwords would expire on a Friday. Passwords changed on a Friday are often not remembered on a Monday, so this may lead to lots of help-desk calls. As employees often start their employment on a Monday, setting a password expiration cycle that works on multiples of 7 days means that most employees subsequently change passwords on a Monday, and have the rest of the work week to use them and get them embedded in their memories. Of course there will be exceptions to this, such as people who change passwords or start their employment midweek, but there isn't much you can do about that.

Continued on page 2: Limitations of the Password Policy

Continued From Page 1

Limitations of the Password Policy
Before concluding our discussion of the Password Policy, it is worth pointing out one major consideration. Both the Password Policy, and the Account Lockout Policy that we will discuss in Part Two of this series, are set on a domain-wide level. If you have numerous departments with differing policy needs, this represents a problem. For example, a research department with very high security needs and a customer service department with only moderate security needs will end up with the same security settings if they are in the same domain. Of course, you could create multiple domains, and then divide the departments up among the domains according to their security requirements, but that is a major design decision, and one that might not be practical if your Active Directory infrastructure is already in place.

With this in mind, perhaps the best way to use the policies is simply to configure the policies at the highest security level required within the entire domain. Departments with lower security needs simply end up being more secure than necessary, but there is nothing wrong with that.

Next Week…
In part two of this article, we'll look at how you can configure the Account Lockout Policy to increase the authentication security of your systems even further. We'll also look at what non-computer based policies you should have in place to govern password use. Until then!

---

Drew Bird has been working in the IT industry since 1988. He has a wide range of experience gained from many years of designing, managing, implementing, and supporting networked environments. Drew now divides his time between consulting work and writing and delivering technical training courses. He also writes a regular feature here on Enterprise Networking Planet, and authors technical books.