security questions

John Ioannidis ji at
Thu Aug 7 19:14:18 EDT 2008

piers.bowness at wrote:
> John Ioannidis wrote:
> | Does anyone know how this "security questions" disease started, and
> why 
> | it is spreading the way it is?  If your company does this, can you
> find 
> | the people responsible and ask them what they were thinking?
> The answer is "Help Desk Call Avoidance"; allow the end-user to fix
> their own account without having to get someone on the phone. This is
> simply an available mechanism in the spectrum between easy-to-use and
> rock-solid security.

As the discussion so far indicates, and as published papers show, the
security of these "security questions" is lower than the security of
the password.
> | My theory is that no actual security people have ever been involved,
> and 
> | that it's just another one of those stupid design practices that are 
> | perpetuated because "nobody has ever complained" or "that's what 
> | everybody is doing".
> Your theory is incorrect. There is considerable analysis on what

Can you reference it please?  There has been some analysis on the 
entropy of passphrases as a password replacement, but it is not relevant.

> constitute good security questions based on the anticipated entropy of
> the responses. This is why, for example, no good security question has a
> yes/no answer (i.e., 1-bit). Aren't security questions just an
> automation of what happens once you get a customer service
> representative on the phone? In some regards they may be more secure as
> they're less subject to social manipulation (i.e., if I mention a few
> possible answers to a customer support person, I can probably get them
> to confirm an answer for me).

The difference is that when you are interfacing with a human, you have 
to go through a low-speed interface, namely, voice. In that respect,
a security question, coupled with a challenge about recent transactions,
makes for adequate security.  The on-line version of the security 
question is vulnerable to automated dictionary attacks.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list