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?

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.

  • 7
    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
    Commented Jun 6, 2011 at 21:30
  • any text entered should treat numpad number with same value as regular keynoard numbers.
    – happy
    Commented Jan 15, 2013 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. Commented Jan 15, 2013 at 19:09
  • 1
    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.
    – supercat
    Commented Aug 24, 2014 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.

This research study was posted here in a previous question: https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxyZXVzYWJsZXNlY3xneDozNDcwNDhmMmE2MmJiMDkw

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.

  • 2
    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.
    – Null
    Commented Jan 15, 2013 at 3:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .