Modernizing Authentication — What It Takes to Transform Secure Access
Not knowing any better, our gatekeeper will surely open the gate and allow the enemy in. Once inside, he'll wait until our guard is down, then open the gate himself to allow his cohorts in and all we keep inside will be lost in no time.
Colorful as this analogy is, how close is it in fact to the truth of our situation? Are we really that vulnerable? The answer is yes, I'm afraid we are. If our enemy, a hacker or a corporate spy, comes to our system with a recognizable user name and armed with the corresponding password our only remaining protection will be our internal vigilance mechanisms, which especially on larger systems, are liable to be less than adequate to reliably detect the intruder.
Being thus the weakest chink in our armor, it is critical that passwords are protected to the maximum extent possible. To accomplish this on an enterprise wide basis requires the establishment of a sound password maintenance policy. To create a policy of this sort requires some careful consideration and planning. If the policy is hurriedly thrown together, it will almost certainly be weaker than is desirable.https://o1.qnsr.com/log/p.gif?;n=203;c=204634421;s=15939;x=7936;f=201702151714490;u=j;z=TIMESTAMP;a=20304455;e=i In general, passwords must be unpredictable and the policy that protects them should be as unpredictable as possible. This being so, your friend's policy is probably not the one you want. One that I might suggest is probably no better.
To be as unpredictable as possible it should be one devised within the enterprise and should be malleable, changing its characteristics from time to time. There are, however, some considerations that can be listed that can provide some food for thought in the process of devising a policy.
One size does not fit all.
Users of the system fall into a variety of categories ranging from a guest to a system administrator. The policies for these users will not all be the same. A guest password may be public and static, for instance. The guest would be so limited in the scope of their capabilities that such a password might be adequate for the need. It might even be non-existent. This would not be sufficient for a system administrator! While a little extreme, this does illustrate the point.
The following categorization illustrates a possible grouping. The top level passwords, that is, the built-in system administrator (or root) passwords, should be known to as few personnel as possible, except that one or two may not be the best of ideas. For contingency reasons, three or four may be the best minimum number.
In my own little organization, four people hold this key - two of whom are actually well trusted outsiders. The next level, or category, is the group of people who are system administrators, that is, whose user-Ids have administrator privileges. This group can be further sub-divided into the built-in groups within Windows, such as Enterprise Admins, Domain Admins, etc.
The number and scope of these sub-divisions will depend on the size and complexity of your organization and what makes sense for it. Operators make up the next category. This category comprises the built-in operator groups such as Print Operators, Back-up Operators, etc. There is no sense in re-inventing the wheel! Users and Guests round out the categories list.
Page 2: continued...
In your organization there may be more or less 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 avoiding the "one size fits all" problem.
Windows Group Policy allows for the requirement for minimum complexity and though there may be one, I can not think of a really good reason to not enforce 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 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, or perhaps 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 most strongly discouraged from ever writing 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 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 life 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 use 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.
Discuss this article at AntiOnline, Enterprise IT Planet's home for security forums.