I am looking for ways to verify the user in order to reset their passwords. 2 commonly used ones:

  • Email verification
  • Secret question

I wonder which will you recommend? I am trying to avoid having to use email at all (users won't need to provide emails, most hosts limit emails sent). But Secret Question alone seems a little unsecure. What do you think?


5 Answers 5


Personally, secret questions annoy me a lot. The predefined questions are either so easy that someone could simply google and/or guess the answer. Or the question are so obscure, that I don't know the right answer and give a fake one (which leads to problems if you really try to recover your password) ... really I can't remember the name of my teacher in 1st grade!

Worse, if you let the users define their own question and answer they will do really, really dumb stuff (like putting the password in the question!).


Email verification is good enough for most applications

It may not be perfect but most people expect and accept this kind of approach. Overall, a good process is as follows

  1. User clicks "Forgot password"
  2. System generates a one-time token (UUID), stores it in the database marking it as new
  3. Email containing a HTTPS password reset link with the UUID sent to user email account. This is the weakness because it assumes that the user is authorised by their access to their email account, not the secret information you previously shared.
  4. User clicks the link and the system verifies that the UUID is unused
  5. Assuming all is well, the user is taken through the password reset process, which first marks the UUID as used and then accepts password updates.
  6. The password is salted and hashed and then stored in the database. The plaintext version of the password is never persisted. Ever.

Valuable data?

If the data you are trying to protect is much more valuable (tax returns, bank details etc) then you need a stricter implicit authorisation process (see step 3 previously). This is usually in the form of a letter containing the UUID (usually hidden within a tamperproof envelope). The user is then expected to activate the password reset process and manually enter the UUID.

Extreme data

Finally, if the above is not enough then you're into the realms of identity management. You'll be breaking out the proof of address, driving license, passport, birth certificate, personal references and all the other frippery necessary to establish beyond reasonable doubt that the user is who they say they are. And then you proceed to step 5.


For Earth sake, do not use secret questions. In a week I usually have no idea what I could have answered there less in a year.

Email verification will do just fine.

And never send the password in plain text per email. Never even store the password, store a hash of it.


Use email verification.

The Secret Question approach has multiple problems.
I may have forgotten the answer
I would have spelled the answer differently (with a leading upper case word, and that programmer would have forgotten a equalsIgnorecase)

The actual problem is that the user forgot the password. And the secret question approach wants him to remember 4 other things since he forgot something.

Many users end up taking a screenshot of the question answer screen for future reference - the very purpose of the password is lost.


Avoid secret questions if at all possible.

The biggest problem with secret questions is that we live in an age with social media and powerful search engines. Nearly every traditional question that is used can be answered with some basic OSINT (e.g. Mother's maiden name, first pet/car/school, favorite band/video game/book, street you grew up on, etc.). You could have them make up their own secret questions, but that opens up problems with users picking easy questions or giving out hints to what their password is.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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