| > | My theory is that no actual security people have ever been involved,
| > | 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.
RSA sells a product that is based on such research.  I don't have
references; perhaps someone else does.

I think the accurate statement here is:  There's been some research on
this matter, and there are some reasonable implementations out there;
but there are also plenty of "me-too" implementations that are quite

In fact, I've personally never run into an implementation that I would
not consider worthless.  (Oddly, the list of questions that started
this discussion is one of the better ones I've seen.  Unfortunately,
what it demonstrates is that producing a useful implementation with
a decent amount of total entropy probably involves more setup time
than the average user will want to put up with.)

| > 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.
Actually, this cuts both ways.  Automated interfaces generally require
exact matches; at most, they will be case-blind.  This is appropriate
and understood for passwords.  It is inappropriate for what people
perceive as natural-text questions and answers.  When I first started
running into such systems, when asked for where I was born, I would
answer "New York" - or maybe "New York City", or maybe "NY" or "NYC".
I should have thought about the consequences of providing a natural-
text answer to a natural-text question - but I didn't.  Sure enough,
when I actually needed to reset my password - I ended up getting locked
out of the system because there was no way I could remember, 6 months
later, what exact answer I'd given.

A human being is more forgiving.  This makes the system more vulnerable
to social engineering - but it makes it actually useable.  The
tradeoff here is very difficult to make.  By its nature, a secondary
access system will be rarely used.  People may, by dint of repetition,
learn to parrot back exact answers, even a random bunch of characters,
if they have to use them every day.  There's no way anything but a
fuzzy match on meaning will work for an answer people have to give
once every couple of months - human memory simply doesn't work that

I learned my lesson and never provide actual answers to these questions
any more.
                                                        -- Jerry

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to