News Stay informed about the latest enterprise technology news and product updates.

10 tips in 10 minutes: Password policy considerations

The following 10 quick tips offer expert advice on password policy considerations, from educating users on the importance of a password policy to enforcing minimum length passwords.

As part of the 25 password hardening tips in 25 minutes series, the following 10 quick tips offer expert advice on password policy considerations from experts and contributors.


TABLE OF CONTENTS: Password policy considerations
   1. Know what makes a strong password policy
   2. Create logical policies
   3. Change policy for local accounts
   4. Change policy for individual accounts
   5. Know how to expire passwords
   6. Determine who should have stronger passwords
   7. Manage multiple unique passwords
   8. Enable complex passwords
   9. Know when to disable default password filter
   10. Enforce password policy

Return to 25 password hardening tips in 25 minutes.


Tip #1: Know what makes up a strong password policy
[ Return to 25 password hardening tips in 25 minutes ]

A strong password policy can go a long way. A strong password policy will:


  • Insist on frequent password changes
  • Require long passwords composed of random combinations of upper and lowercase letters, numbers and special characters
  • Not allow blank passwords
  • Check to ensure passwords are not repeated
  • Prevent the use of any part of the user's name or user ID
  • Not allow the use of common dictionary words
  • - Excerpted from Roberta Bragg's Hardening Windows systems' book excerpt Strengthen the password policy


    Tip #2: Create logical policies
    [ Return to 25 password hardening tips in 25 minutes ]

    Changing the password policy for an organization may be a rather large undertaking. If users can now use blank passwords or short ones, and if they do not have to meet complexity rules, making them comply with more restrictive rules may prove to be beyond your authority. This is something that you should evaluate, and it is really of the utmost importance. No single change can have as much impact on the security of your networks.

    You can, however, immediately improve the security of your networks by creating a logical password policy for a select group of individuals: those who have elevated privileges in the enterprise, in the domain, or on some systems. A prime target for such a policy are system and network administrators. IT admins and their management should be receptive to changes that will improve information security.

    Perhaps you can spearhead change by making the adoption of a strong password policy the result of working together to improve security. Working out ways to strengthen the policy without making it overly difficult to adhere to will make it easier to obtain and implement a stronger organization-wide password policy.

    - Excerpted from Roberta Bragg's Hardening Windows systems' book excerpt Strengthen the password policy


    Tip #3: Change policy for local accounts
    [ Return to 25 password hardening tips in 25 minutes ]

    Local accounts on servers and workstations cannot be entirely eliminated. Windows computers that are domain members retain their local account databases. Any accounts in these databases cannot be managed by the domain password policy. A password policy for these accounts should also be in place. This policy can be a very strong policy. In many organizations, local accounts are not used, with the exception of some administrative accounts on some servers. If accounts are not used, then password policies can be very restrictive; if accounts are used, then password policies should be very restrictive, and it should not be difficult to obtain approval, since many of these computers are controlled by IT.

    Local password policies for NT 4.0 computers, and for those Windows computers joined in a Windows NT 4.0 domain, must be configured on the local system, or via custom scripts. Local password policies for computers joined in a Windows 2000 or Windows Server 2003 domain can be set and managed via Group Policy. Remember, password policies set at the OU level affect only the local user accounts of the computers in the OU. To use Group Policy to manage the password policy of local user accounts:

    1. Place the accounts of servers for which the same password policy is required, in the same OU.
    2. Create a GPO and link it to the OU.
    3. Open the GPO for editing and modify the password policy.
    4. Close the policy.

    - Excerpted from Roberta Bragg's Hardening Windows systems' book excerpt Strengthen the password policy


    Tip #4: Change policy for individual accounts
    [ Return to 25 password hardening tips in 25 minutes ]

    In addition to domain password policy and local password policy, changes can be made at the account level. That is, you can impact the password policy of an individual account. In many cases, changing policy at the account level is a way to prevent the weakening of password policy for the domain. Options may also strengthen policy.

    For example, in some cases, it may be required to store a password using reversible encryption. This is not recommended; however, it is still better to do so for a couple of accounts, using the Store Password Using Reversible Encryption option, than it is for all accounts in the domain. Another questionable option is Password Never Expires.

    Expiring passwords is a way to make sure users change their passwords. Blocking this action weakens that technical control. However, if accounts are used by services, then passwords must be manually changed—the service program will not recognize or respond to reminders to change passwords and will simply be locked out when the password expires. Using the account level option allows the domain-level password policy to require periodic password changes. Incredibly, I still find domains where no user accounts are required to change passwords, because service accounts cannot.

    While both of these options can weaken individual account protection, setting account level policy can strengthen protection for an individual account. For example, the option Smart Card Is Required for Interactive Logon can be set for an individual account. Long before smart cards can be installed as the primary authentication mechanism for an organization, it may be possible to require their use by administrators, or by other privileged users.

    Finally, other options are temporary controls that can do much to prevent unauthorized account usage, the goal of a password policy in the first place. These options include:

  • User Must Change Password at Next Logon
  • Account Is Disabled
  • Account Is Sensitive and Cannot Be Delegated
  • - Excerpted from Roberta Bragg's Hardening Windows systems' book excerpt Strengthen the password policy


    Tip #5: Know how to expire passwords
    [ Return to 25 password hardening tips in 25 minutes ]

    Because there can only be one password policy for a domain, whatever you set for the password expiration will be in effect for all users, with the exception that you can set an account to not expire at all. There are two possible solutions to this problem:

    1. Create a separate domain for the high-risk areas, which would have other advantages as well, as they could manage other differences (length of password, history, account lockout, etc.).

    2. While there is only one enforceable password expiration policy per domain, there is no reason not to procedurally insist on group passwords being changed on whatever schedule. Scripts could also be written to check on this and possible e-mail users who failed to follow the policy, or make some other changes that would be effective in enforcing the policy. Of course, writing custom software could also be used to enforce more frequent password changing.

    - Excerpted from Roberta Bragg's Can we have mroe than one password policy?


    Tip #6: Determine who should have stronger passwords
    [ Return to 25 password hardening tips in 25 minutes ]

    Just because the generic password policy for all users is set at one level and partially enforced by technical controls, you should still have another, stronger password policy for administrators and others with sensitive accounts. While only one password policy per domain can be technically enforced, you can require some users to have stronger passwords. You'll have to give them further training, requiring longer passwords and other techniques. You may have to audit them by using a cracking/audit tool, but it will be worth it.

    - Excerpted from Roberta Bragg's Hardening user passwords


    Tip #7: Manage multiple unique passwords
    [ Return to 25 password hardening tips in 25 minutes ]

    The reason for using a unique password for every account is to limit the risk. If someone obtains a password or cracks an account, you want to limit them from getting access to more data. For example, if you have two accounts, one with administrative privileges, and one without, I hope you have a different password for each of them. It is always a good rule to have different account passwords. Certainly, however, you must weigh this risk against the risk posed by writing down or otherwise storing passwords.

    Writing down passwords or storing them electronically is not in itself bad -- it's where and how you store the recording. Having a PDA file of your passwords and no encryption on the PDA and no password on the PDA is not very secure. Locking the list up somewhere or having an encrypted file on a device that is not accessible from the network might be reasonably secure. You are going to have to weigh the risk of each possible solution to the problem. And one other caveat… if the 16 passwords at work exist because 16 different resources must be accessed, it may be that having the same password for some of the accounts may not be as large a risk. After all, a good single-sign-on implementation might provide you a single account that allows you to access all resources. Remember, no security rule is absolute. There are super "best practices" that must be tempered by the organizations and situations "best security."

    - Excerpted from Roberta Bragg's How to manage multiple unique passwords


    Tip #8: Enable complex passwords
    [ Return to 25 password hardening tips in 25 minutes ]

    When complex passwords are enabled, existing accounts that do not meet the requirements are unaffected until the password is changed. It's recommended that you require a password change the next time they log on. However, in a larger environment, you may want to stagger this requirement, and in any organization, make sure this does not catch users by surprise. Provide ample warning, training and above all, solicit support from all management. Nothing is worse than implementing new security without support.

    - Excerpted from Roberta Bragg's Enabling complex passwords


    Tip #9: Know when to disable default password filter
    [ Return to 25 password hardening tips in 25 minutes ]

    Normally when a custom password filter is installed, it replaces the Windows password filter or even the entire logon process. When a log on is attempted, Windows looks at all valid password filters, so preventing the use of its own is important if you want to rely on yours entirely. You may have already written your own, though you can find an example script. Microsoft also reveals its own passfilt.dll and instructions on how to write and use your own filter.

    Now, to prevent Windows from using passfilt.dll simply requires setting the password policy to NOT require complexity. This setting is at "Windows Settings/Security Settings/Password Policy/Password must meet complexity requirements." Simply change it to disabled if it is enabled. If your password filter is also checking for password size, history and other Windows password settings, you can set them to null here as well. I wouldn't, however, change the "Store passwords using reversible encryption" setting. It's disabled by default for a reason. It allows storing passwords in an easily recoverable form. This is required by some classic non-Windows clients, and that's why its available. It is generally used as a user account variable and not as a system wide variable and only if necessary.

    - Excerpted from Roberta Bragg's Disabling the default Windows password filter


    Tip #10: Enforce password policy
    [ Return to 25 password hardening tips in 25 minutes ]

    If your password policy does not exceed the technical controls Windows offers, setting those controls for enforcement will suffice. However, no password policy should be without requirements, including failure to post passwords on monitors, not sharing passwords and so on. In addition, there are technical controls you may want that cannot be done in the Windows password policy, such as requiring number placement in the middle of passwords.

    Use the following strategies to enforce password policies:

  • First, purchase and use a password auditing tool. These tools can be used to provide information on how long it may take to crack a password -- even weak passwords. While you may not be able to tell if numbers are placed in the middle of a password, you can tell if a password is easily cracked and not in policy.
  • Second, do periodic site searches looking for passwords that are written down.
  • Third, include a punishment for non-compliance in your security policy. If there is a violation, there should be consequences.
  • - Excerpted from Roberta Bragg's Hardening user passwords


    Return to 25 password hardening tips in 25 minutes.


Dig Deeper on Enterprise desktop management