So far we have established the value of properly implementing password self-service and successfully tackled building effective password governance. The next step is to develop “challenge questions.â€
Challenge questions – definitely a double-edged sword
A key benefit of any password self-service system is the “forgot password†feature. If a user forgets their password, they click on the link, provide their userID, and are prompted to answer some personal questions to authenticate themselves. If they can answer the questions correctly, they are allowed to reset their password.
This is a big cost savings for most organizations – and a big convenience for users when implemented properly.
It’s a simple concept, but coming up with the right questions can be surprisingly tricky. Here are a few things I have learned while implementing password self-service:
- In reality, users can answer whatever they want to the questions, as long as they remember the answer. Most users don’t realize that and assume they have to answer truthfully, so if they are presented with sensitive questions like mother’s maiden name, they may choose to not use the system rather than make something up.
- It is human nature to remember things that are meaningful more than things that aren’t. If the user is presented with a question that doesn’t have meaning to them – or whose meaning changes over time – they could probably make up an answer, but they might not remember it later.
- If the answers can be easily researched or guessed, the system can be readily compromised. Unfortunately, easy to remember is often synonymous with easy to guess, socially engineer, or research.
Picking the right questions
So what is the best way to develop the questions?
First, determine if there is enough information in the HR system to eliminate the need for developing questions. The easiest way to handle password self-service setup is to auto-populate answers from an HR system so that users don’t have to register answers to questions before using the system. Also, the HR system can continue to update the answers if any of them change over time, allowing for less confusion on point-in-time questions. In this case, care should be taken to avoid asking questions that coworkers would easily know the answer to – such as employee numbers, email addresses, and birthdays. Also keep in mind that the full social security number (or even last four digits thereof) is considered to be a restricted data element that should not be stored in an identity management system.
Although using HR data can be a very simple and effective way to set up the challenge questions, many companies will find that there is not enough usable information in the HR system to make this work – the answers have to be private enough so that others can’t guess them or look them up, but common enough so that the users themselves will know and remember them.
So back to our original question – what is the best way to develop the questions?
Answer: Set up focus groups. Engage HR, InfoSec, management from various areas of the organization, and a sampling of different types of end users to help create questions, and to test their usability. It will be the job of InfoSec to make sure that the questions aren’t too easy to guess or research, and HR will ensure that the questions aren’t offensive to anyone (or violate union-related restrictions, if that applies).
Hopefully, the self-service system allows users to select questions they feel comfortable answering from a larger list. If that’s the case, it greatly simplifies things for the design team because it allows for the creation of a number of questions, and each user can select the subset that they feel is most appropriate for their experience. In fact, organizations that do not yet have a technology selected should add “user-selectable challenge questions†to the requirements list and weight the importance on the higher end.
Some systems, however, don’t allow for question selection – all users have to answer all of the questions presented, which creates an additional layer of complexity:
- The popular questions (mother’s maiden name, city of birth, etc.) are also available as public record – if someone wanted to know that information badly enough, they could find it (this is true regardless of the selectability of questions to answer)
- “Favorites†(favorite movie, favorite food, etc.) can change over time, or they might not apply to all users (e.g., I don’t have a favorite sport so when I’m asked that, it’s hard for me to come up with a memorable answer)
- Family questions can be problematic in this day and age: not everyone has a spouse or a child and increasingly, not everyone has two parents
- Residence questions are more difficult these days: people move around a lot more than they used to
- Education questions can also be problematic. For example, I work in retail and we have a fixed-question system. Some of our employees are high school students, so we can’t ask about high school graduation. Many of our employees have never gone to college even if they are old enough, so we can’t ask questions about that, either.
When faced with a fixed question set, guide the focus group to come up with point-in-time questions that avoid the problems above. For example:
- On what street were you living when you turned 16 years old? (Rarely will there be an employee younger than 16, this level of detail is hard to research, and it allows for multiple residences at that age, but it may also be difficult for the user to remember)
- What is the name of the first high school you attended? (Doesn’t imply graduation, and also allows for attending multiple schools)
- What is the first name of the person who primarily took care of you as a child? (Could be confusing for someone who had two engaged parents, but this question does not imply parents, and it is hard to research. It could be easy to guess by coworkers who get to know the person)
Once the questions are finalized, communicate them to the end-users so they become familiar with the concept. Even if the self-service tool implementation is a few months out, it’s never too early to engage the end users
In the next article, we’ll develop a strategy for creating initial passwords.