Which password policy setting should you use to prevent users from reusing their old passwords too quickly?

3.2 Zero-knowledge password policy check

A Password Policy Check (PPC) is an interactive protocol between a user and a server, where server's password policy f = ((kD, kS, kL, kU), nmin, nmax) and the public parameters pp←Setupλ of a password hashing scheme. ℋ is used as common inputs. If and only if f(pw) = true at the end of the PPC execution, the server accepts a hash value h for any password pw of the client's choice. A PPC protocol is a proof of knowledge of the password pw and randomness sP, sH used for hashing. A Zero-knowledge Password Policy Check (ZKPPC) protocol with zero-knowledge characteristic prevents the server from leaking any information about the password pw.

Let ℋ=SetupPPreSaltPPreHashPSaltPHash be a randomized password hashing scheme. A ZKPPC protocol is a PPC protocol with zero-knowledge property between a prover (user) and verifier (server), such that: f(pw) = true and PHashppP sPsH=h, where P←PPreHashpppwsP.

Password Policies in SQL Server 2005

Password policies are a new feature in SQL Server 2005. So what are password policies? They are a series of rules enforced to ensure passwords in SQL server follow standards set forth in the operating system via group policy.

Password policies can be turned off and on in SQL server. There may be reasons for not using password policies overall, or just on specific accounts.

Using the Group Policies Console

The easiest way to use the group policy console is to start the management console by typing “MMC” in the run box in Microsoft Windows. To access the run box, click the Start menu, and select the run box. The Microsoft management console has other functions besides controlling group policy.

Once the MMC is started, you need to click Add/Remove Snap-in. The “Add/Remove” snap-in option is available on the file menu (see Figure 6.1).

Figure 6.1. Adding the Snap-in (Part 1)

Click the Add/Remove Snap-in menu selection, and a dialog that allows selection of snap-ins to be added will be presented. It is recommended that you select only the add-in for group policy; otherwise, the menu can get very cluttered very quickly.

Scroll down and select the Local Group Policy Object, and click the Add button (see Figure 6.2). Note that when using Microsoft Windows 2003 or Microsoft Windows XP, the dialog boxes may look slightly different.

Figure 6.2. Adding the Snap-in (Part 2)

When you add the snap-in after selecting it and click OK, the selection of which computer you wish to manage dialog will be presented (see Figure 6.3). Note that it’s not necessary to be logged in to the computer to be managed, but the account used needs administrative rights on the computer to be managed.

Figure 6.3. Selecting the Computer

After you select the computer (in most cases it will be the local computer), the initial Group Policy Management console snap-in screen will be presented (see Figure 6.4).

Figure 6.4. The MMC Initial Screen

As one can see in group policy, there are also a number of other items to be controlled. It is strongly suggested to refrain from changing anything, unless the impact is known, as there is no “undo” for the settings in group policy. Once a change is made, if the previous value is forgotten, there is no way to go back and see what it was.

In order to use the group policy snap-in to control the password policies, expand the tree under “console root” on the left-hand pane.

Expand each of the nodes under “Windows Settings” until Account Policies is shown.

Some Independent Advice

Group policy is complex in the way it’s applied. Group policy is applied at different points (at the domain or group level in Active Directory). Active Directory provides an option that will not allow group policy settings to be overridden. In the event an option is configured to not be overridden at a higher level, even if it has been set at the local level, the setting won’t take effect if it’s set via Active Directory.

This is why it is important to involve the appropriate groups in your organization when working with group policy.

Password Policies

The following password policies can be enforced in SQL Server 2005:

■

Password history

■

Minimum password age

■

Maximum password age

■

Minimum password length

■

Complexity requirements

Figure 6.5 depicts the password settings in the management console for group policy.

Figure 6.5. Group Policy for Passwords

Let’s discuss each of these options in more detail.

The “Enforce password history” option is used to prevent users from reusing old passwords. This makes the system more secure; a user needs to use a new password (one that has never been used before) each time they change the password. Valid values for this are between 0 and 24. The default is 24 on domain controllers and 0 on stand-alone servers. It would be bad practice to install SQL server on a domain controller, so I would surmise that it will be 0 on your server. If this option is to be used, it is a good idea to also use the “Minimum password age” option as well.

The “Minimum password age” option is used to set the period of time in days that the password must be used before the user can change it. On the surface, you’d wonder why you’d want to use this setting, but it has an important use. It also prevents users from changing the password in order to defeat the “Enforce password history” option, by going through passwords until they get back to an old favorite. This also helps to discourage users from changing their passwords so frequently that they forget them. The default is 0, which allows the user to change the password at any time. Note that the “Minimum password age” must be less than the “Maximum password age.”

The “Maximum password age” is used to set the period of time in days that a password may be used before requiring the user to change it. This can be set from 0 (never expire) to 999. Note that the “Minimum password age” must be less than the “Maximum password age.”

The “Minimum password length” option is used to set the minimum password length for a password. This can be set from 0 to 14. When the “Minimum Password Length” is set to 0, it allows for any length password.

The “Password must meet complexity requirements” option is used to set complexity requirements, causing the password to be more secure and less apt to guessing.

The attributes of the password must be as follows when the complexity requirements option is enabled:

■

The password must not contain the user’s account name or parts of the user’s full name that exceed two consecutive characters.

■

The password must be at least six characters in length.

■

The password must contain characters from three of the following four categories:

English uppercase characters (A through Z)

English lowercase characters (a through z)

Base 10 digits (0 through 9)

Nonalphabetic characters (for example, !,$,#, %)

Complexity requirements are enforced when passwords are changed or created.

Some Independent Advice

It’s usually a good idea to enable the “Password Must Meet Complexity Requirements” option; however, it’s also a good idea to communicate this to your users prior to enabling this, as it can lead to user confusion when they attempt to change their passwords and may result in an increase in support calls to your helpdesk.

Using the Local group policy console to administer settings is easy. Double-click on the setting to be changed and a dialog box will be presented where changes will be made. The console checks the values to be sure they are within the proper range. Double-click on the option, and a dialog box similar to that in Figure 6.6 will be presented.

Figure 6.6. The UI for Administering Settings

Note

If more information is needed about what a setting does, the Group Policy Snap-in provides an explanation for each of the settings. When an item is double-clicked, a tab to see a detailed explanation is available. Clicking the Explain tab will present the information (see Figure 6.7).

Figure 6.7. A Group Policy Setting Explanation

The explanations are very clear and concise, and they usually show the default values as well as ranges for the settings.

Best Practices According to Microsoft

According to Microsoft, these are some best practices to follow:

■

Set the maximum password age for passwords to expire every 30 to 90 days,

■

If the “Enforce password history” selection is used, be sure to set a minimum password age.

Account Lockout Policies

The account lockout policies are as follows:

■

Account lockout threshold option (number of invalid logins before lockout)

■

Account lockout duration (amount of time locked out)

■

Reset lockout counter after n minutes

Figure 6.8 depicts the Account lockout settings in the management console for group policy.

Figure 6.8. The Account Lockout Group Policy

We’ll now discuss each of these options in more detail.

The “Account lockout threshold” option is used to set the number of invalid logins before the account is locked out. Valid settings are 0 (which is never lock out an account) to 999. Once an account is locked out, it needs to be unlocked by an administrator, or the “Account lockout duration” time needs to expire. The default is 0.

The “Account lockout duration” option is used to automatically unlock the account after a period of time. The time is in minutes. Valid settings are 0 (which is never unlock an account until an administrator resets it) to 99,999. This is especially useful for organizations that have busy administrators or no off-hours support.

The “Reset lockout counter after n minutes” option is used to determine how many minutes need to elapse before the failed logon attempt counter is reset. The range is 1 to 99,999. In order to use this setting, the “Account lockout threshold” must be set. The reset time must be less than or equal to the “Account lockout duration” (if the account lockout duration is set).

Using Password Policies

First, to use password policies in SQL Server 2005, password policies need to be enabled. This is accomplished by turning on password policies in SQL Server when creating a login.

Here is an example of creating a login for SQL Server using T-SQL, which will use the policies defined in the operating system:

CREATE LOGIN Robby with

 password=‘Test$12345’,

 CHECK_POLICY = ON,

 CHECK_EXPIRATION = ON

Figure 6.9 is an example of creating a login for SQL Server using SQL Server Management Studio, which will use the policies defined in the operating system.

Figure 6.9. Creating a Login That Uses Password Policy

When you are creating a login, be sure to check the “enforce password policy” checkbox so the login will adhere to the password policy rules defined in the operating system. This is a good idea unless there is a compelling reason not to. The same holds true with password expiration.

It’s possible to enable one or both of the settings, because they function independently of each other.

Best Practices According to Microsoft

•

Mandate a strong password policy, including expiration and a complexity policy for the organization.

•

If SQL logins are required, ensure that SQL Server 2005 runs on the Windows Server 2003 operating system and use password policies.

•

Outfit the applications with a mechanism to change SQL login passwords. This includes application logins.

•

Set MUST_CHANGE for new logins where practical.

Some Independent Advice

While group policy can make your environment more secure when it comes to using SQL logins, it’s still a better practice to use Windows logins wherever possible.

Password Change Policies

After installing the SQL Server engine on the server, you will probably begin creating SQL Server accounts. Using SQL Server 2005 or newer, creating accounts that use SQL Server Authentication will give you a few checkboxes, shown in Figure 5.9, which you need to understand so that you know how these options work. If you are in a Windows NT 4 domain, then these options will not be available to you and they will be grayed out as Windows NT 4 domain’s password policies are not used by Microsoft SQL Server. If you are using Windows Azure SQL Database these options will also not be available as Windows Azure SQL Database does not enforce domain policies. If you are using SQL Server within a Windows Azure Virtual Machine then the options will be available if the Virtual Machine is a member of your Active Directory domain.

The first checkbox, “Enforce password policy,” tells the SQL Server that the password must fit within the password requirements of the Windows domain, or the local security policy defined on the server (if the server is not in a Windows domain). The password policies that are being enforced by the first checkbox are the “Enforce password history,” “Minimum password length,” and “Password must meet complexity requirements” policy settings.

The password policies cannot be checked after the login has been created. The password policies are only evaluated when a new login is created or when the password for an existing login has been changed. The system function PWDCOMPARE can be used to check accounts for known or blank passwords easily enough as shown in Example 5.8. The system function accepts three parameters, two of which are the most important and the third of which only needs to be used against a password hash from a SQL Server 2000 system.

Example 5.8

Querying the SQL Server instance for all logins which have a blank password.

The first parameter is the known password that is being checked in plain text, while the second is the password hash. Either a table, such as the sys.sql_logins catalog view, can be queried or a specific hash can be passed in. The third parameter accepts only a zero or a one with a default of 0. When a one is specified this indicates that you will be passing in a password hash which was generated by a SQL Server 2000 or older instance, when you are running the PWDCOMPARE statement on a SQL Server 2005 or newer instance.

Note

Group Policy Definitions

All six of the group policy settings – the five that SQL Server uses and the one that SQL Server does not look at – which control password policies within a Windows domain are explained in Chapter 3 in greater detail. Because they are covered there, they are only discussed at a high level in this chapter.

The second checkbox, “Enforce password expiration,” tells the SQL Server that this account must change its password based on the “Minimum password age” and “Maximum password age” settings that come from the domain or the local security policy.

The third checkbox shown in Figure 5.10 is the “User must change password at next login” option. In Figure 5.10 the option is disabled because the “Enforce password expiration” option is not selected. If the “Enforce password expiration” option were checked, then the “User must change password at next login” option would be available. By checking this option and clicking OK the next time the user attempts to log into the database engine, the user will need to change their password.

FAQ

How the Password Change Process Works

If the user connects to the SQL Server with an account that has an expired password, then they will need to be prompted to change their password. If the user is using SQL Server Management studio, they will be prompted to change they password automatically as shown in Figure 5.10. The same will happen when using the SQLCMD command line tool.

However, when using your own application to log into the database, such as a Windows Forms application, the application will need to know how to prompt the user for a new password, as well as what to do with the new password in order to change the password for the SQL Account.

The advantage of having and using these policies is that all the SQL Authentication accounts that are configured to follow the policies meet the password policies that have been defined on the domain.

Password Policies and Protections

Password policies are an area that is often treated too casually in network operations. In Windows 2003, it is extremely desirable to create and enforce strict password policies. Password attack tools are often free or available at low cost, and they allow an attacker to retrieve passwords for existing accounts or identify poor practices and vulnerabilities in a very short amount of time. Passwords should be changed at frequent intervals, should be a minimum of 8 characters (14 is preferred, since many password crackers can now retrieve 8-character passwords in a day or two), and should follow complexity rules. This means that the password should have letters, numbers, special characters, and upper/lower case in their construction. Passwords should not be names, parts of usernames, or common dictionary words or their derivatives. When trying to secure networks and resources, it is no longer an acceptable condition to accept insecure passwords or policies.

Windows 2003 allows us to configure these policies locally on workstations and standalone servers via the Local Security Policy management console in Administrative Tools. These locally created policies will apply to local accounts on the given machine only. If creating the policies in an Active Directory domain, the policies can be configured via the Domain Security Policy Group Policy Object. If a member of the domain, the domain policies will override the machine policies if the user is authenticating with the domain.

Group Policy Management Editor

The local security policy application will also help you to implement portions of your company's user security policy. You can configure user account settings and password policy settings. But if you want to configure these options for your domain, you will have to use the Group Policy Management Editor, as shown in Figure 5.4.

Password Policy: The Password Policy section, as shown in Figure 5.5, allows you to configure how passwords will be handled and restrictions around how passwords are set. This allows you to force users to create stronger passwords. This helps protect again password guessing attempts. The settings available here are as follows:

Enforce password history This option allows you to control how often passwords can be reused. On Windows Server 2008 R2 domain controllers, the default is 24 passwords.

Maximum password age This option specifies how long a user can go between password changes. The default on domain controllers is 42 days.

Minimum password age This option specifies how long a user must have a password before it can be changed. The default on domain controllers is 1 day.

Minimum password length This option specifies how long a user's password must be. The default on domain controllers is seven characters.

Password must meet complexity requirements This option sets requirements for what characters must be used in a password.

Store passwords using reversible encryption This option controls how passwords will be stored. Some applications need to be able to access passwords. This option will help allow this.

Account Lockout Policy: The Account Lockout section, as shown in Figure 5.6, allows you to configure account lockout settings. Account lockout allows you to lock an account after repeated failed login attempts. This helps protect against brute force password-cracking attempts. The settings available here are as follows:

Account lockout duration This option controls how long an account will be locked out. By default, this option is disabled because account lockout is disabled.

Account lockout threshold This option controls how many bad login attempts will cause an account to be locked. By default this option is disabled.

Reset account lockout counter after This option controls how long the system will wait after the last unsuccessful attempt before it resets the lockout counter. By default, this option is disabled because account lockout is disabled.

Kerberos Policy (only available on domain controllers): The Kerberos Policy section, as shown in Figure 5.7, allows you to configure how Kerberos will be handled in your domain. Kerberos is the default authentication method used in Windows 2008 R2 domains. The settings available here are as follows:

Enforce user logon restrictions This option controls whether every session ticket request is checked against the user rights policy. This option is more secure, but it does take up extra network bandwidth. It is enabled by default.

Maximum lifetime for service ticket This option controls how long service tickets will be valid. The default is 600 min.

Maximum lifetime for user ticket This option controls how long user tickets will be valid. The default is 10 h.

Maximum lifetime for user ticket renewal This option controls the timeframe for which a Ticket-Granting Ticket can be renewed. The default is seven days.

Maximum tolerance for computer clock synchronization This option specifies the maximum difference in time that can exist between the client and the domain controller. This is to help prevent replay attacks. The default is five min.

Password Policies

Password policies allow administrators to enforce password history, age, and complexity and also use reverse encryption. Some options you can enforce include:

Enforce password history This will allow or disallow the availability of password histories. Changing this setting to 1, for example, would make it impossible for the user to use the last password he or she had used and force the user to create a new one. However, the user could reuse the password he or she had prior to the current one, because only one previous password would be remembered. The default setting is 24.

Maximum password age This is used to set the age for the password. After the number of days specified has been met, the password will expire and need to be reset. If password history is enforced, the user will need to change the password to a new one. If not, the user could reenter the same password. It makes little sense to set a maximum password age unless you also enforce password history. The default setting is 42 days.

Minimum password age This setting allows you to specify a time that a password must be in effect before it can be changed again. You can use this to keep users from continually changing their passwords. The default setting is one day.

Minimum password length This setting allows you to set a minimum length for passwords. If a user tries to set a password that is less than the minimum specified length, he or she will receive a message that the password is unacceptable. The default setting is seven characters.

Password must meet complexity requirement You can set passwords to meet a complexity requirement, which means they must contain both uppercase and lowercase letters and numeric characters to make them more difficult to guess. If a user tries to set a password that doesn’t meet the complexity requirements, he or she will receive a message that the password is unacceptable. This would stop users from using dictionary or easy-to-guess passwords. This policy is set to either Enabled or Disabled (you cannot define the specific required characteristics for the password within this policy; Microsoft has preset them).

Store password using reversible encryption for all users in the domain This setting allows you to use reversible encryption to store user passwords. Reversible encryption is not secure because it is the same as storing password in plaintext. This setting should be used only when necessary for compatibility purposes. By default, it is disabled.

Password Change Policies

After installing the SQL Server engine on the server, you will probably begin creating SQL Server accounts. Using SQL Server 2005 or newer, creating accounts that use SQL Server Authentication will give you a few checkboxes, shown in Figure 4.3, which you need to understand so that you know how these options work. If you are in a Windows NT 4 domain, then these options will not be available to you and they will be grayed out as Windows NT 4 domain’s password policies are not used by Microsoft SQL Server.

The first checkbox, “Enforce password policy,” tells the SQL Server that the password must fit within the password requirements of the Windows domain, or the local security policy defined on the server (if the server is not in a Windows domain). The password policies that are being enforced by the first checkbox are the “Enforce password history,” “Minimum password length,” and “Password must meet complexity requirements” policy settings.

The password policies cannot be checked after the login has been created. The password policies are only evaluated when a new login is created or when the password for an existing login has been changed. The system function PWDCOMPARE can be used to check accounts for known or blank passwords easily enough. The system function accepts three parameters, two of which are the most important and the third of which only needs to be used against a password hash from a SQL Server 2000 system.

The first parameter is the known password that is being checked in plain text, while the second is the password hash. Either a table, such as the sys.sql_logins catalog view, can be queried or a specific hash can be passed in. The third parameter accepts only a zero or a one with a default of 0. When a one is specified this indicates that you will be passing in a password hash which was generated by a SQL Server 2000 or older instance, when you are running the PWDCOMPARE statement on a SQL Server 2005 or newer instance.

Note

The second checkbox, “Enforce password expiration,” tells the SQL Server that this account must change its password based on the “Minimum password age” and “Maximum password age” settings that come from the domain or the local security policy.

The third checkbox shown in Figure 4.3 is the “User must change password at next login” option. In Figure 4.3 the option is disabled because the “Enforce password expiration” option is not selected. If the “Enforce password expiration” option were checked, then the “User must change password at next login” option would be available. By checking this option and clicking OK the next time the user attempts to log into the database engine, the user will need to change their password.

FAQ

How the Password Change Process Works

If the user connects to the SQL Server with an account that has an expired password, then they will need to be prompted to change their password. If the user is using SQL Server Management studio, they will be prompted to change their password automatically as shown in Figure 4.4. The same will happen when using the SQLCMD command line tool.

Figure 4.4. The Change Password Dialog Shown in SQL Server Management Studio

However, when using your own application to log into the database, such as a Windows Forms application, the application will need to know how to prompt the user for a new password, as well as what to do with the new password in order to change the password for the SQL Account.

The advantage of having and using these policies is that all the SQL Authentication accounts that are configured to follow the policies meet the password policies that have been defined on the domain.

Windows Authentication Group Policies

There are a total of six policies that you can set within Windows that affect the domain or local password policy. However, Microsoft SQL Server only cares about five of them. The policy with which the SQL Server is not concerned is the “Store passwords using reversible encryption” policy. This policy tells Windows if it should store the user’s password using a two-way encryption process, instead of a one-way hash. Enabling this policy presents a security vulnerability on your domain as an attacker could download the list of all users and passwords, then break the encryption on the passwords and have full access to every user’s username and password. Due to the security issues with this setting, the setting is disabled by default and should remain so unless there is a specific reason to enable it. The typical reasons to enable it include using Challenge Handshake Authentication Protocol (CHAP) through Remote Access or Internet Authentication Services (IAS). It is also required if one or more Internet Information Service (IIS) servers within the Windows Domain are using Digest Authentication.

The five password policies that the SQL Server does recognize and follow are the following:

Enforce password history;

Maximum password age;

Minimum password age;

Minimum password length;

Password must meet complexity requirements.

Each of these settings has a specific effect on what the passwords can be set to and should be fully understood before changing the password of an SQL Authentication Login.

The “Enforce password history” setting on the domain (or local computer) is not a Boolean, although the name sounds as though it would be. It is in fact the number of old passwords for the account that the SQL Server should track so that passwords cannot be reused. The setting has a valid range of 0 (or no passwords) to 24 passwords. The more passwords that are kept, the greater the chance that the user will forget their password, but the lesser the chance that someone will break into the system via an old password. The default on the domain is 24 passwords.

The “Maximum password age” setting tells the SQL Server how many days a password is valid. After this number of days has passed since the last password change, the user will be prompted to change the password. If the password is not changed, the user will not be able to log into the database instance. This setting accepts a value from 0 (never expires) to 999 days, with a default value of 42 days.

The “Minimum password age” setting tells the SQL Server how many days from the time a password has been changed until it can be changed again. This setting prevents the user from rapid-fire changing their passwords to eat up the number of passwords specified by the “Enforce password history” setting. Without this setting, or with this setting set to 0, when the user’s password expires, the user can simply change the password 24 times and then change it to the same password that it was before effectively breaking the password requirement feature. This setting accepts a value from 0 (allows immediate password changes) to 998 days, with a default value of 1; however, this setting has a practical upper limit of one day lower than the setting for the “Maximum password age.” If you were to set this setting to the same value or higher than the “Maximum password age” setting, then the users wouldn’t ever be able to login until after their passwords had expired.

The “Minimum password length” setting tells the SQL Server how many characters need to be in the password for the password to be acceptable. This setting can be any value from 0 (allowing a blank password) to 14 characters, with a default value of 7 characters. It is typically recommended to increase this value from the default of seven to a higher number such as nine characters. While this will make the password harder for the user to remember, it will also make it exponentially harder for an attacker to guess. The “Password must meet complexity requirements” setting tells the SQL Server that all passwords must be considered “strong” passwords. There are several requirements to having a strong password beyond what one would normally consider. By default this setting is enabled:

The password cannot contain the username within it.

The password must contain characters from at least three of these four categories:

Lower-case letters (a through z);

Upper-case letters (A through Z);

Numbers (0 through 9);

Symbols ($, #, @, %, ^ for example).

The “Minimum password length” setting and the “Password must meet complexity requirements” settings work together very nicely. Without configuring the “Minimum password length” setting the user would have the ability to have a three character password even with the “Password must meet complexity requirements” setting enabled. This is due to the fact that the “Password must meet complexity requirements” setting doesn’t include a password length. The only length requirement which the “Password must meet complexity requirements” forces is a minimum of three characters due to the fact that the password must contain one character from each of the four groups listed earlier in this chapter.

When you enable the “Enforce password policy” setting for an SQL Authentication Login, this enforces the “Enforce password history,” “Minimum password length,” “Minimum Password Age,” and “Password must meet complexity requirements” settings against that login. When you enable the “Enforce password expiration” setting for an SQL Authentication Login, this enforces the “Maximum password age” setting against that login. In order to enable the “Enforce password expiration” setting against an SQL Authentication Login, you must also enable the “Enforce password policy” setting. However, you do not need to enable the “Enforce password expiration” setting if you enable the “Enforce password policy” setting.

Note

When working on an SQL Azure database, the login must meet the password complexity settings that Microsoft has defined. As of the summer of 2010, this means that the password must be eight characters in length and meet the complexity requirements shown above. There is no way to configure a login to an SQL Azure instance to not meet these requirements, for the SQL Azure instances do not support using the check_policy parameter to disable the policy checking.

Password Strength

The first defense against a password attack, if that is one of the factors in your authentication, is to simply have a strong password. Passwords are usually the first line of defense on workstations and network devices. A simple password by itself is weak security. A password is a series of characters that can be shared or cracked through brute force methods, so the best solution would be to create a password as strong as possible, but one that can still be remembered. Most organizations have found that merely making recommendations for employees to use stronger passwords isn't all that successful.

Consider the Password Policy from SANS,2 which may appear to be the policy Stepan had fallen victim to, but is in fact a good policy. SANS defines a strong password as having the following characteristics:

Contains both upper and lower case characters (e.g., a-z, A-Z)

Has digits and punctuation characters as well as letters (e.g., 0-9, [email protected]#$%^&*()_ +|~-=\`{}[]:”;'<>?,./)

Is at least fifteen alphanumeric characters long and is a passphrase (Ohmy1stubbedmyt0e)

Is not a word in any language, slang, dialect, jargon, etc.

Is not based on personal information, names of family, etc.

Passwords should never be written down or stored online. Try to create passwords that can be easily remembered. One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase might be “This May Be One Way To Remember” and the password could be “TmB1w2R!” or “Tmb1W>r~” or some other variation.

Operating System Requirements

In order to use password policies, SQL server 2005 needs to be running on Windows Server 2003 or later. SQL 2005 password policy functionality depends on the NetValidatePasswordPolicy application program interface (API), which is only available in Windows Server 2003 and later versions. Also, password policies need to be enabled for that machine via group policy. Password policies are part of Windows group policies. Group policies can be applied to different containers in Active Directory, as well as locally on the machine.

Some Independent Advice

Since group policies can affect other Windows services such as windows user passwords and passwords used by service accounts, be sure to completely test your changes in a test environment before making any changes to your production environment. It’s very important to understand the impact of any changes you are going to make before making them.