Leadership By Numbers

Start off by opening up the administration client and choosing "Edit Multiple Passwords" under the Tools/Certification drop menu.

Now, you'll see the requestor box for entering names and their passwords. Guess what? The names are only there as a suggestion--the identity of whoever is accessing the ID is never checked. The concept for multiple passwords is something called "missile-lock," where two people have to enter their own password and the combination of both permits access. The name is merely a reminder of who has a password for the ID. We can use this information to our advantage.

Instead of a prompt for a user's name, how about a question? It's possible to simply put the following sentence into the entry for a name: "What is your favorite color?". Match "blue" as the password and now you have something different. You have a question for an answer you already know. This isn't a bad solution, ask a question for which you know an answer and you don't need to remember some weird password. If I'm the only person who will ever need to access the certificate, then a simply knowledge question is workable--but that's not likely, is it? Other people need to be able to use this certificate, and I'm guessing they have their own favorite color.

In the example I'm showing, I ask the social security number (SSN) of the CIO. That's a piece of information that would not be widely known, but could be easily found within the organization. Now the bar has been raised, the question can refer to information that only a few have access, or is very specific organizational knowledge.

Not good enough? Let's keep raising the standard.

Notice that there is a box for entering the number of required passwords. If I put in "2," then two correct passwords must be entered. In order for me to access the certificate I have to be able to correctly answer two of the questions. Having multiple passwords makes it much tougher to run a dictionary attack against the ID. It's even possible to further increase the difficulty of compromising the certificate.

If I choose "blue," I'm relying on knowledge I possess alone--that makes personal questions pretty reliable. Problem is, personal questions aren't a good enough solution for certificate passwords. Relying on organizational knowledge helps out, because now a wider number of individuals can access the certificate ID. But, it may be too much of a challenge to come up with unique organizational information, or the security level is simply higher for some companies than for others. We can raise the bar one more level.

In the final example, I have a table of random numbers. This table is stored separate from the certificate ID. When I need to use the certificate, I'll need to rely on the table to answer the questions. The values in the table, by themselves, are insufficient to access the ID. I need the questions to ferret out the answers, and unlike questions about color or staff SSNs, there is no indication of what the answer is, as it is stored in the table.

1. Use questions for which only you know the answer, and you've created unique passwords that never require being written down, you don't have to struggle to remember, and cannot be compromised
2. Use questions that are based in organizational knowledge and only a privledged few will be able to respond.
3. For highly secure installations, a password list may be necessary, and the table is a workable solution. The values don't actually reveal the passcodes, until the ID is accessed and the questions guide the administrator.

That's it ! Now you can password protect your certificates, even if the answers are never written down and the IDs need to be accessed by future administrators you have yet to meet.