I'm building a web application and I'm actually writing a code that allows users to choose their secret question and answer used to identify them if they forget their passwords.

I'm a little bit confused here because many well-known websites offer only a list of restricted and predetermined questions and do not allow users to type their own secret questions. However this decreases the security as hackers may easily guess the answers by social engineering, information gathering... (well the secret question is not secret anymore).

Is there any security risk in letting people store their own secret questions and then let them select it among other random questions when they need to identify themselves.

I'm aware of SQL injection risk, so let's suppose that my code is secure and that data is stored in the right way.

  • It is an additional measure to sending the password-reset-link to a registered email or a code to a phone number. Probably aimed at limiting robots. It should not be primary means of identification. And anyway there's no guarantee users won't enter a dumb question.
    – techraf
    Mar 29, 2016 at 8:03

3 Answers 3


You make a comment that predetermined security questions are more likely to be guessed by attackers than user-defined questions. That assumes your average user will design a better (e.g. more secret, less guessable) question than the people implementing the system. This doesn't seem to be true for most users.

In one lab study subjects only spent an average of 15 seconds coming up with their own security question. That's very little time to think about the characteristics of a what makes a good security question. In a different study researchers asked people creating security questions what they considered important factors when designing their questions. 70% identified "memorability" as a very important factor, while only 44% said "security" was very important. So letting users write their own questions will often result in worse security because they're focused on making them easy to answer, not resistant to guessing.

I was able to actually observe this behavior a bit in a study I conducted a few years ago on user-defined security question/answer pairs that were leaked during several website database breaches. I found that many of the questions were the same type of thing you'd expect to see in predefined security questions lists: Mother's maiden name, pet's name, birthplace. But this included bad questions like 'what is your favorite color' where some answers are much more likely than others, and making five guesses (blue, purple, green, red, black) would correctly match 75% of user answers.

Worse, some users would choose to completely undermine the security of the question through their choice. Some users (15% on one site, 2% on another) would make the answer match their question. A small number (0.2% and 1.8%) would even list their password as their question. In these cases anyone able to view the question could then use that info to log in as the user. You can implement controls to check questions as users submit them and try to prevent this behavior, but it's pretty hard to enforce against a user determined to circumvent it.

Security questions aren't a very good method of authenticating users, but allowing user-defined questions tends to be an even worse solution. If you are determined to use security questions, they should be evaluated and chosen by the people most qualified to evaluate their pros and cons.


Basically, people are rubbish at coming up with questions. They come up with things like "Type 'secret'" or "My name" - they're worthless at best, and actively harmful at worst ("Usual password" - the answer to the question will tend to be stored in plain text...). Even pre-determined questions are fairly bad - they tend to either be easily guessed, or easily forgotten (for example, if you ask "What was your first car?", and your site caters for 18 year olds, it's a matter of looking on Facebook and there is almost certainly a photo of them with it...).

Best practice is to email a password reset link to the stored email address (avoiding exposing whether the entered address exists or not), which is time-limited and one-use. You can then ask a question if you want, but since you have already verified that they have access to the email address associated with the account, it's probably best to assume they know anything that might commonly be emailed (address, date of birth, partner's name, etc.), so it may not add much, if anything, in terms of security.

  • My application is a backoffice , I don't want to only rely on email , you know some people are not aware of the risk in letting outlook open when they are out of office,
    – storm
    Mar 29, 2016 at 9:27
  • 1
    Might be a good opportunity to send confirmation text to corporate mobiles, if you have them. Otherwise, it's even worse than the internet version - people in offices often know more about each other than they let on, just from chats. I suppose the best option would be to train people to lock machines, but that's a difficult battle to fight...
    – Matthew
    Mar 29, 2016 at 9:41
  • ..Or let machines auto-lock when not in use? If it's a back office app, I assume you're running on some sort of directory anyway.
    – ndrix
    Mar 29, 2016 at 19:42
  • If there is that little trust/security in the office then email the reset to a supervisor for confirmation as part of a reset workflow.
    – Dave
    Mar 29, 2016 at 22:43

In addition to the other answers a reason to avoid user chosen secondary secret questions is that they may contain "inappropriate" content.

This is generally only a concern where the question and answer will be visible to administrative staff (for example where the secret question and answer will be used as part of a call center authentication process)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.