Question
In the case of security questions being used to reset an account password, what is considered best practice for handling case-sensitivity on the security question answers?

Scenario
An account password reset process I'm working on works in three steps. The first step asks the user to provide three pieces of identifiable information, including their user name, birth date, and identification number. Once they've passed that check, they are asked their security question(s) (which they set up previously). If they've passed that check, they set up a new password.

So, should we require case-sensitivity on the security question? Some internal discussion is pointing us in the direction of "no." One justification we have come up with is, say we used that same security question if the user called us as a check to verify their identity. If they get the answer right, they get the answer right. They're not spelling out the case of the answer to us verbally. So, should we do it on a web form?

I can't seem to find an "industry standard" or a "best practice", so I'm hoping to get some feedback from people with experience in this practice or from security matter experts.

Of course, "best practice" is not to use security questions. These should be better known as "in.security questions", since they are effectively a backdoor, and very complicated to implement securely.
–
AviD♦Jun 6 '11 at 21:30

any text entered should treat numpad number with same value as regular keynoard numbers.
–
happyJan 15 '13 at 5:13

like AviD said, security question answers are pretty old schemes. If possible involve a two step verification process like Device verification (for eg. gmail) , or if thats not possible then make the user have another email in profile (Which should not be same as their primary/account login email) so that if they forget password, you send the password reset email to their secondary email. Would be safe even if primary email is hacked.
–
Novice UserJan 15 '13 at 19:09

A key question should be what a user will be allowed to do upon answering a security question. If satisfying it is merely a first step before sending out a password-recovery email, then an attacker would have relatively little to gain by cracking it, in which case it might be reasonable to even store the thing as plaintext and allow part of it to be marked as "important" [e.g. if the question was "Second grade teacher", and the user answers "[Emil] Jones", it may be useful to have the system accept either "Jones" or "Emil Jones" as answers.
–
supercatAug 24 '14 at 0:18

3 Answers
3

"Security question answers" are akin to auxiliary passwords, which users will not use on a daily basis. Remembering a password that you almost never type is hard. Requiring exact case is likely to make the user fail to answer properly.

On a theoretical point of view, a "security question" is already a huge weakness, which you tolerate because some users will forget their password, and you want to handle that case with as much automation as possible, and not asking any security question would be even worse security-wise. Hence, the added value of security questions is that they allow a not-totally-open password reset process which can nonetheless be conducted automatically, i.e. at minimal cost for the server. Case sensitivity would probably remove much of that value. Actually, I would even recommend normalization by suppressing whitespace, punctuation and accents.

Security questions are basically another password. Ideally it should thus have the same properties as a password i.e. reasonable length (greater than 8 characters) being the most important to defend against guessing and bruteforce.

Its conclusions are that complexity is not that important against an online entry. Thus if you check for basic dictionary words, username etc, have sufficient length and implement an account lockout or exponential backoff, there is no significant benefit in also requiring complexity.

Of course the best would be to eliminate secret questions and add an out of band password reset method such as SMS one time password or even email one time password / link. Or stop managing passwords altogether and support an OAuth (e.g. Facebook connect) or Open-ID (Google etc) based method of authentication.

As was stated in both prior answers, "security questions" are just passwords and disguise, and should be treated as such. We don't set your passwords to some easily guessed or publicly available values, so why do we do it to security questions? It is asking for trouble, and I personally know people who got in trouble this way.

I always give completely made up answers to security questions and then treat them the same way as real passwords, i.e. use password management software. I seriously recommend to everyone to do the same.

This question is being asked from the perspective of someone creating a password recovery scheme, not the end user. The vast majority of people have no idea what password management software is.
–
NullJan 15 '13 at 3:40