MI-80

People have said many things over the years reflecting traditional wisdom regarding password policies. Every administrator and every environment functions by their own rules, but it is not often people discuss how these rules have changed. This becomes more of a problem with the advancement of computing power and its slow deterioration at the security of passwords in general. First off, let us address one of the most common password policy mistakes administrators make: password expiration. Overly aggressive policies, such as monthly password changes, ensure some users use the weakest passwords possible or they write them down. This is not mentioning additional administrative and help desk overhead via the steady stream of forgotten passwords that need reset. This point also brings into question the conventional wisdom that passwords should never be written down. The fact is both of these practices may be detrimental to modern environments. Certainly, passwords must expire, and this time should reflect the sensitivity of the data in question. However, constantly forcing users to change their passwords is counter-productive. In mass, there is little use in forcing users to change their passwords more often than once a year. This permits them to commit a secure password to memory, avoiding side effects like writing them down, and decreasing administrative and help desk overhead. Of course, one rule is not so simple. Perhaps management and technical staff should change their passwords quarterly; so it varies by not only environment, but position as well. For the masses though, stringent password expiration policies are a hindrance for someone who “just wants to do their job.” Keep this in mind when developing a password policy, because it is counter-productive to your organization to inhibit workers from performing their assigned tasks as effectively as they can. In addition, anytime you negatively affect user’s productivity, they will work around your policies and protections wherever they can. Writing passwords down is also another common misconception among IT environments. There is nothing inherently horrible about users writing their passwords down, permitting they treat it like any other sensitive paper document. In fact, the average user is very well versed in how to protect small paper documents; after all most are likely to have some cash in their wallet at any given moment. The problem is not that users write their passwords down, but that they do not have the mindset to treat that paper with the level of protection it deserves. Sticky notes of passwords under their keyboard is a security risk: sticky notes of their passwords folded up in their wallets act as helpful reminders enabling them to use stronger passwords and not forget them after long weekends or summer vacations. Complexity requirements are also becoming prohibitively difficult. Seven digit phone numbers are broken up into two parts because time has shown the average person unable to effectively recall seven random digits at once. However, it is common for businesses to require passwords of eight to ten characters, requiring a combination of letters, numbers, case, and even special characters. This is a recipe for an angry user base who will work around security requirements. This problem is a difficult one to tackle. Modern computers can chew through the once-secure shorter and less complex passwords, so administrators rightly step-up their policies to match the new threat. The key here is finding a middle ground. Require passwords to be longer and stronger, but back-off rules prohibiting the use of children’s name or anniversary dates for example. Instead, train users to create a secure password by combining several personal facts that are easy to remember to them. A password like Robby19750101 may look like gibberish to us, but to the woman who married Robby on January 01, 1975, that is easy to remember. It also contains upper-case, lower-case, and numbers, which combined with its length make it resistant to brute-forcing. Additionally, as passwords become more complex, lengthen the time between password changes and investigate in a better long-term solution, such as hardware tokens for dual-factor authentication. These last two points actually have little to do with end users, but focus on failures by administrators to assess the password landscape as a whole. First, while password reuse across varying levels of asset importance has become a common concern, most organizations have a poorly structured policy to manage it. For example, an IT staff may be well aware that they need separate login credentials for their corporate email and administrative access to the company’s core routers, however what is the best solution here? Too many administrators develop overly complicated schemes that end up with “password burn-out” because they have 15 or 20 passwords for various assets throughout the enterprise. Separating levels of access is important, but your solution must remain usable. A good password scheme must be simple, easy to document, and of course, secure. Think of your password scheme as a pyramid, with the least secure passwords at the bottom, used across the most systems, and at the top a select few vital assets that use a much more secure password. Of course, there may be levels in-between, but keep the entire pyramid to three or four levels at a maximum. Make the passwords towards the bottom, which you use most frequently, adequate for common assets such as blogs, email, etc. (6-8+ characters, moderately complex, changed annually) secure, but easy to type. Inversely, for core network assets you may only access a few times a year, develop longer passwords that do not necessarily need to be easy to type. The goal here is to separate drastically different levels of access while minimizing the number of passwords you must remember, so look at what stands to work best in your environment. Also, document what systems use what passwords. This simple step makes changing passwords much easier on systems which do not integrate with your infrastructure, such as firewalls or other networking equipment that do not hook into Active Directory. Finally, the perfect password scheme is only as strong as the systems in-place to circumvent it, mainly your password reset policy. If someone can guess a users favorite color or make a random phone call to have their password reset, nothing else matters. Stringent policies and help desk training must be in-place to ensure adequate identification and authorization prior to any password reset. Likewise, automated systems such as those so commonly found on websites must utilize a trusted and layered approach. For example, permit users to enter their own challenge questions instead of selecting from a small range of pre-written ones. Better yet, do this, and allow the user to fill out a bank of three to five such questions, and then prompt for any random two or three during a password reset. Then, once they answer these questions, email them a password reset link to continue the verification chain. Of course, simple measures like limiting how many tries this system can take before locking out an account mitigate brute-forcing and similar attacks. Also consider that password reset links may sit in email boxes for awhile; ensuring they expire promptly and are only good for one use further help prevent abuse against an automated reset system. So, while password based security has taken hits in recent years, not all is lost. Environments and users evolve, and so must password policies. Policies must strive to combine maximum security with the least hindrance to user productivity, meaning a proper balance of password lifetime, handling, complexity, management, and resetting policies. Striking the right balance for your environment may prove time consuming, but is the right choice in the end for ensuring a happy, and secure, user base.