Harden Your Windows Network with Strong Passwords

Part One: Many security-minded admins scoff at passwords as tissue-thin protection against malicious users. But with Windows 2003 Server's password policy tools, you can do a lot to tighten down your most basic line of defense.

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.

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.