In his third article, Elton Hay discusses the problems and dangers of storing answers to challenge questions.
Most online systems with user accounts have automated the password reset process in order to cut down on their helpdesk costs. In the process of automating the password reset, the use of a challenge question and answer has become common.
But what this represents is two doors into an account. On the main door, the challenge question is "What is your password?" Get the right answer and you are in. The question on the second door is often one created by the account user. If they can answer it correctly, again they are admitted into the account. One big issue with this approach is how to get the strength of locks on the two doors to be comparable. Another issue is who creates the question on the second door, the user or the system?
Hash up your data
Assuming that the system has a challenge question and answer, there is the issue of how the system stores the question and answer. For years now systems have been storing passwords in a hashed form instead of in the clear. The main reason for this is that clear passwords are readable by people - people get their hands on the password file by one means or another, and not all people are trustworthy. The hashed form keeps a significant number of people from knowledge of the true password.
The challenge question and answer data are a later add-on. They are very often added to the same password file or database as additional fields. This is very natural, as there is a one-to-one relationship to each account, and it is data that is being accessed and used at the same time. But, these fields are usually added as clear text fields, thus we are back to where we were with clear passwords. Anyone who gets their hands on this data has the keys to accessing all the accounts.
When passwords were (or are) stored in the clear, someone could use that password to gain access to an account and could do so in a manner that often went undetected. With access to the challenge question and answer a person can gain access to an account, but in the process they have to reset the password to some new value. This gains them access, but now the chances are high that this access will not go undetected. However, they may use the account for some time before this trespass is detected. The person hacking the account could also change the challenge question and answer, effectively locking out the original owner of the account.
Should you store the answer in an encrypted form or a hashed form? If there is a need for someone other than the user to know the answer, storing in an encrypted form could be appropriate. One such need could be someone in a helpdesk using the answer to authenticate the user, and needing to know the answer in clear text ahead of time. But, if the user cannot remember the answer, and has to contact the helpdesk to have the password reset, other means of authenticating the user can be done without the helpdesk having to know the answer to the challenge question. In general, the answer needs to be treated just like the password, and stored in a hashed form.
Using encrypted storage
There is some debate as to how to store the challenge question. After all, the challenge question needs to be presented in the clear to the user when trying to reset their password, and thus is knowable. But if the question is one that has been created by the user, then I think that it should be stored encrypted. Someone who gains access to the password/challenge question/answer file can catalog questions stored in the clear, and use them to significantly narrow a dictionary attack.
The possible answers to a question like "What is the color of my ..." is a very short list compared to what comprises a dictionary attack on a password. In my studies, the answer 'blue' occurs more times than all other colors combined.
Making it strong
On the other hand, if the challenge question(s) is system supplied, then they do not even need to be stored in the password file at all. The question will become known to hackers over time, but all that needs to be stored with the password and hashed answer is some indicator of which question was used.
When storing encrypted fields in a very large database, it is very helpful to also store some indicator as to which encryption key was used, and when the field was encrypted. There are times when it is appropriate to change the encryption keys. If the database is very large, it is difficult to start such a process and have it run to completion without some system problem or some user access intervening. It is much more appropriate to do the process in chunks, but then you need to have these two additional fields to help keep track of which key was used to encrypt the data.
When all is said and done, challenge question and answers are generally much weaker than passwords. The use of system-supplied multiple questions helps increase the strength of this authentication process. Until the problems with challenge question and answer are properly dealt with, use of this technique poses more security risks and exposures than the helpdesk savings it attempts to create.
Elton Hay, CISSP, is a security consultant working within the infosecurity industry.
