Stern messages and harsh penalties concerning these practices are often ineffective, because most people's memory simply isn't enhanced by punishment. Those who have difficulty remembering names, for example, have far more success when they resort to mnemonics or imagery-based association methods, as opposed to being sanctioned or threatened. Insistence on unworkable security rules may even lead to a tragedy of the commons (download PDF), where people stop caring about much besides their own functional well-being within an IT environment even as they accept actions that diminish the security of everyone.

In an IT context, notes and patterns introduces an element of predictability that one wants to avoid when using passwords -- or so we're used to thinking. In practice, however, the trade-off between accepting some degree of patterning and recording of passwords is often well worth the return in increased password strength and rotation.

The solution, such as it is? It's worthwhile to provide instructions on how to create a password that's easy to remember but hard to guess. Some examples are here and here. This is a great alternative to mandating password requirements that go too far -- for example, by demanding they can't even be derived from dictionary words -- which may lead to widespread contempt for security guidelines.

Why Jane can't learn

On a document management and extranet project several years ago, we discovered one unpleasant (and more or less unexpected) side effect of strong security: It was preventing self-education and learning of new technologies.

The system in question was intended to serve operations and development information to individuals according to the systems installed in their local operations center. This reduced the licensing costs by ensuring that people had access to the documentation and tools necessary for their work -- and only their work. Accordingly, access to documentation for other systems, or to more advanced tools for operations and development, was perceived as unjustified and a license violation.

It doesn't take long for this to create a stifling environment, and put personnel in the Catch-22 position of having to know information or have certain skills before being granted access to that information and the resources to develop those skills.

The answer is simply to back off, or provide an alternative in a non-production environment, either by borrowing some corner of the technical test environment or by establishing a dedicated educational environment. An extra or unused copy of software, development tools, and/or documentation should be made available through an internal library, or installed on a system dedicated to testing and education.

Unless employee turnover is constant and licensing restrictions are intractable, there's little excuse for preventing learning and cutting off career growth. This small expense in both simple and complex IT environments can usually be justified by pointing out that lack of knowledge and human error are the single largest contributors to security problems.