Modernizing Authentication — What It Takes to Transform Secure Access
We can build our fortress with towering fifty-foot high, four-foot thick walls. We can build a moat thirty feet wide to surround those walls. And we can even man the castellation with the finest archers. But all will be for naught if the enemy crosses the drawbridge in the guise of one of our fellows and gives a good password to the gatekeeper.
Not knowing any better, our gatekeeper will surely open the gate and allow the enemy in. Once inside, the enemy 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's critical that passwords are protected to the maximum extent possible. Accomplishing this on an enterprise-wide basis requires establishing 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.
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 for yourself, and thus one that I might suggest is probably no better.
To be as unpredictable as possible, it should be a policy devised within the enterprise and should be malleable, changing its characteristics from time to time. There are, however, some considerations that can provide some food for thought in the process of devising an effective policy.
One Size Does Not Fit All
Users of the system fall into a variety of categories ranging from guests to system administrators. 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. For that matter, it might even be non-existent. Of course, the same would not be sufficient for a system administrator!
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, although limiting it to just one or two people might 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, Backup Operators, etc. There is no sense in re-inventing the wheel! Users and Guests round out the categories list.
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.