Leadership By Numbers

Before I get to the password tip, I'd like to impress that if you don't know who Charlie Kaufman is, then you need a quick introduction. Charlie Kaufman was a Distinguished Engineer at IBM, where he was Chief Security Architect for Lotus Notes and Domino. He is co-author of the book "Network Security: Private Communication in a Public World" published by Prentice Hall and served on the National Academy of Sciences expert panel that wrote the book "Trust In Cyberspace". He currently serves on the Internet Architecture Board and chairs the IETF’s Web Transaction Security working group. He is also currently the editor of the new Internet Key Exchange protocol document for IP Security Protocol Working Group (IPsec). He holds over 25 patents in the fields of computer security and computer networking. And, (I missed the memo) he is now employed at Microsoft.

At last year's Lotusphere conference, he made a very interesting suggestion on dealing with frequent password changes by creating a compound-password. I've shared his concept with a number of security professionals, and they agree that it seems to be a workable idea. Most work sites are requiring frequent password changes: 90 days is common, but I know public and private sector organizations that are down to 30 days. The average user doesn't like frequent changes because they are being required to create difficult passwords, commit them to memory, and then change them every few months. So, what do most users do? They write down their passwords. Of course, this is a bad practice and nullifies the entire effort to maintain security.

Charlie's suggestion is to train users to build their passwords in two parts. The first part would be a traditional password, but more on the simple side (e.g., "egg2whip"). This first part could be written down some place secure (not on a sticky note pasted to the monitor). The second part (I'll call it a 'root') would be six or seven very random characters (e.g., "H[8t=m") which is not written down, but committed to memory and added to the first part. This means that the user now has the ability to quickly create difficult compound-passwords that are easy to memorize (and the first part can even be securely recorded).

I'd like to add a few additional comments since I first heard this idea: (1) when I explain this to users, I try not to write down an example of the root. Users will simply copy whatever is put in front of them and then all of them could have similar passwords. A better idea is let the Notes client generate a random, six-character password for their root. There are also web sites that can also generate random sequences; and (2) I suggest that the password length of the root should be limited to six characters. Most people are challenged to remember sequences past seven digits, and the whole compound-password idea only works if the root part of the password can be wholly memorized.

Finally, because I have to maintain too many passwords, I use the concept of rings. I have three rings, and each ring is associated with a specific password root. For instance, most of my web site accounts use the outer root ring. My administration passwords and such use the next root ring. And, finally, very important passwords (e.g., those used to encrypt PKI certificates) rely on a third root. In this fashion, if someone were to compromise an internet account and discovered my root, they could only use that information for the accounts in the outer ring, my certificates would still be at their highest level of security.

Thanks, Charlie