In your organization there may be more or fewer categories than this. Each of these categories would have its own set of rules for passwords. In this way the rules can be set in a manner appropriate to the category and that avoid the "one size fits all" problem.
Windows Group Policy allows for the requirement for minimum complexity, and while there may be one, I cannot think of a really good reason for not enforcing it. Group Policy also allows for enforcing a minimum length. Again, I cannot think of a good reason not to enforce a minimum length. What that value should be is up to you to decide, bearing in mind the factors I discuss below.
Also in Group Policy are options for minimum and maximum age. A lot of strength and a lot of weakness can be introduced into a policy by the judicious, or not so judicious, use of these settings. Countless systems have been compromised as a result of passwords having been written down and thus discovered by unauthorized persons. A password is much safer if you can avoid ever having it written down, or worse, included in an email.
Enforcing age with a policy may not be appropriate for all your categories. It may be better, for example, to allow your admins to judge for themselves when to change their passwords. Those admins must also be strongly discouraged from ever writing down their passwords. With the level of responsibility expected of them, the memorization of a password should not be too much to ask.
As you run down the list of categories, the urgency of not writing passwords down diminishes. All users should be encouraged to memorize their passwords and avoid written reminders. Some policies, however, can make this very hard for some people to do. If the requirement is there to change the password on a monthly basis, for example, some people will have a hard time remembering which one is the current month's password.
Enforcement of password history, such that a password cannot be reused, can exacerbate this problem. Use of odd time periods, such as forty-five or fifty-five days can also make the problem worse. The desire to have a password change before it can be discovered must be balanced against the chance of making it more discoverable. Perhaps a ninety-day lifespan would allow a user to commit their password to memory and use it for most of the time without having it written anywhere.
Additional security can be provided by encouraging users to employ creative methods for remembering passwords. The use of initial letters of a phrase is one of my favorite tools. This works by taking an easy to remember phrase and using its initials for a password. Thus "cousin Bobby was married on August 19" yields cbwmoa19.
Substituting numbers for words that sound like numbers and adding punctuation can yield some excellent passwords: "It is easy for me to cross-stitch" would thus yield "iie4m2c-s." This type of password can provide an excellent means for people to remember their passwords in addition to creating strong passwords. This type of policy is of course enforced by training rather than by Group Policy.
For those who find passwords just too difficult to remember, training can also provide some useful reinforcements. If somebody must write down their password, they can be strongly discouraged from keeping it anywhere near their desk. They could file it, for example, among the customer account files under "G" for "Get a copy of my password" or whatever phrase they find easy to remember ¡ª except one beginning with "P"! The file it is in would of course be unmarked.
It is also important for administrators to remember that users are human. They may have a hard time with passwords and may need support. They should always be encouraged to protect their password. This would include treating every request to have their password reset as if it was a mark of concern for the enterprise's safety.
No matter how frequently it may occur, it should never be a bother to support personnel. A sound password policy includes all these aspects, from Group Policy to training policy. The enterprise's safety depends on it.
This story originally appeared on Enterprise IT Planet.
?
A Password Policy Primer
