It's not too easy to create a reliable and at the same time memorable password.

So, how about a number of memorable questions instead of a single password? (This idea is related to this one)

Let the user create the questions himself. It could be any string, even a random number of symbols, as long as it reminds him of something. It will make signup much longer, yes.

UPD: When a user signs in, he sees the question he is currently answering, so questions work like password hints. Just to clarify.

Answers are stored hashed (with salt fo course) (will additional encryption be useful?). Questions are stored encrypted in a chain, except for the first one - answer for the first question is the key to decrypt the next one, and so on. That guarantees that a potential violator will have to get the answer for each question one by one in a strict sequence, which will make it more difficult to do with social engineering.

Reset in case of forgotten answer for one of the questions: the forgotten part of the chain is deleted, and user is allowed to "grow" a new one instead of it. Of course, we first ask the user if he really wants to do that via email.

Reset in case of compromised answers: the whole chain is deleted, and user is allowed to create a new one. Again, email confirmation.

(this idea relies on email, could be an issue)

Could it be better than standard password auth?

  • 1
    I'm no security expert, but as a user, pls no. I much prefer being forced on a minimal number of characters of 10 for a password than remembering and answering questions, that I will anyway circumvent as soon as I can. Oct 11, 2017 at 19:48
  • (how do I call someone with such a name... let's try @FélixGagnon-Grenier) Nice one :) Well, what if this auth system requires additional security?
    – Andrew Che
    Oct 11, 2017 at 19:51
  • Heh ;) Depending on who the person issuing the requirement is, I'd either explain to them that forcing people to remember questions is not really more secure, or discuss to length what are other options, such as longer passwords, or two factor authorization. Oct 11, 2017 at 19:56
  • @FélixGagnon-Grenier Well, that's my idea, and I actually asked this question to see if this is a good or bad one. You are welcome to explain why is it not more secure, make an answer if you would
    – Andrew Che
    Oct 11, 2017 at 20:01
  • @FélixGagnon-Grenier Hold on. Forcing people to remember questions? Questions in this concept work like password hints, and when you are answering one, you, of course, see the question itself :) Or did you mean remembering answers?
    – Andrew Che
    Oct 11, 2017 at 20:08

3 Answers 3


The trouble with any scheme like this is that people in general are rubbish at choosing good questions, let alone remembering the answers.

In theory there is a huge amount of entropy as there are multiple instances of essentially infinite questions and possible answers.

In practice a significant number of people would still choose common questions and answers. First pet, car, street, place of birth etc

These answers are then vulnerable to both dictionary attacks and social engineering and/or open source research.

  • Exactly. The only way to make this secure is to use so obscure and weird answers to the questions that the questions themself become useless. But if we do that, we have just reinvented the password...
    – Anders
    Oct 12, 2017 at 8:29
  • 2
    So you might as well just use a password manager
    – ste-fu
    Oct 12, 2017 at 9:59

There is certainly a precedent in the industry to use "Security Questions" as a fallback for "I Forgot My Password".

The question basically boils down to "one strong password vs multiple weak passwords".

Some thoughts:

  • Keylogging attacks: if an attacker manages to plant a keylogger, then logging multiple passwords is the same as logging one password.
  • Brute-forcing attacks: people have been trained to make strong, non-dictionary passwords. They have not been so-trained to make strong answers to questions and usually use single-dictionary words. I have never seen data as to whether it's easier to brute-force 5 security answers than to brute-force one good password, but I imagine they're similar.

Direct answers to your questions:

Answers are stored hashed (with salt fo course) (will additional encryption be useful?).

Nah, these are essentially passwords, so treat them like passwords and use best-practice salt&hash password hashing.

answer for the first question is the key to decrypt the next one, and so on. That guarantees that a potential violator will have to get the answer for each question one by one in a strict sequence, which will make it more difficult to do with social engineering.

Yes, but it opens up an even bigger security hole: record&replay attacks. Your authentication protocol is relying on HTTPS to provide your mitigation against replay attacks. That's fine, unless the attacker has broken HTTPS; they have a keylogger on the victim's machine, they have cracked (or stolen) the server's private key, they have installed a MitM root cert into the victim's OS, etc. Now the attacker can see the passwords / answers being sent.

Better than passwords?

This is the primary drawback of traditional passwords. Auth schemes that aim to improve over passwords really ought to fix this or else it's really not an improvement at all.

If you are claiming that your auth method is better than passwords, then it should be in the same category as 2FA methods like code-generating OTP apps, SMS codes, or other challenge-response methods; all of which have the property that the codes are one time use, so even if an attacker is able to record one, the server won't accept a replay of it.

Randomizing which questions are presented, or the order, gives at least some minimal replay protection. For example, it helps with cross-site-request-forgery where the attacker sends a request blindly without being able to see the login page to determine which questions are being asked in which order.

  • Doesn't HTTPS prevent record&replay attacks?
    – Andrew Che
    Oct 11, 2017 at 20:29
  • @AndrewCherevatkin I would say it "mitigates" record&replay, not prevents it since a weakness in HTTPS reveals a vulnerable protocol. This means your protocol is not any worse than regular password, but not any better either. Oct 11, 2017 at 20:40
  • @MikeOunsworth Could you elaborate? I thought TLS prevented replay attacks. Oct 11, 2017 at 20:49
  • @AndrolGenhald Sorry, I'm not being clear. I've clarified my answer. Oct 11, 2017 at 21:07

I'll just recapitulate to make sure I understand properly. You propose to ask the user for a number of question/answer pair, then hash these in the database with informations on the next question hidden in the previous one.

To be honest, I like that, it's very secret service-ish and everything, however it seems to boil down to basically asking the user for several passwords, then ask them to enter these passwords sequentially. That sounds brutal, but I guess that two passwords are more secure than one.

To improve on that, you could randomize the order on each successful login so that next time, the answers have to be provided in a different order.


You must log in to answer this question.

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