Andrew,
Thanks for the response. My company's particular situation is this:
We offer a web-based HR job application for our clients, so we never
actually see them. Because of this we actually do collect some senstive
information as required by the job application such as SSN or driver's
license if applicable. We also store the applicant data and provide a
web-based console for the respective client HR organizations.
The problem, as usual, is human-based. Management tells me (I am the sys
admin) that some of our applicants are extremely computer-illiterate and
email is way beyond them (how they manage the online application but
can't fathom email is beyond me...). So my suggestion of requiring email
was turned down.
Primarily I am looking at password recovery, but also verification for
our corporate clients who often request changes only we can make. In
such a case passwords are not the issue, it's simply user verification.
I think your first suggestion (random numbers on the screen) will work
for us but we still need something more complete. I'm beginning to think
that requiring email is the only good solution but I'm pretty sure that
I'll get outvoted on that again.
Thanks again,
Derick Anderson
-----Original Message-----
From: Andrew van der Stock [mailto:vanderaj@greebo.net]
Sent: Tuesday, October 11, 2005 3:33 AM
To: Derick Anderson
Cc: webappsec@securityfocus.com
Subject: Re: User verification questions
The quick answer is "none of the above". I regularly answer
random characters to them as I refuse to use them.
My litany of inexcusable design frights against these awful
interfaces are:
a) Privacy acts. You have to have a decent reason to collect
and keep private information. These q&a monstrosities do not
qualify.
Businesses have NO reason to know my mother's maiden name.
They have NO reason to know my favorite pet's name.
Therefore, legally, you may not collect this information from
me under most privacy regimes.
b) Public sources. Most of the typical questions can be
derived from public sources (date of birth, license numbers,
credit checks, etc)
c) Laws and regulations surrounding certain types of
information, particularly government identifiers. You must
not collect or use certain pieces of information, such as SSN
or similar government identifiers.
d) "Guess an identity". Most people's favorite color is blue
(about 90% from my survey so far). Similar guess-able answers
can be used to get past help desks with many clerks as they
do not keep a track of the total number of failed accesses
through this back door password scheme.
e) Information Security Policy adherence. These systems are a
weak backdoor password system. Five question Q&A are the
equivalent of two character passwords in terms of entropy (at
best) and do not have any password aging, generally do not
have any brute force provisions (although I don't like
account lockout measures either), and thus fail to meet even
basic security least common denominator practice.
f) It's one factor security - "something you know". I'd have
an excellent chance at answering any of my family's Q&A's,
and a fairly good chance at any of my best friend's Q&A's.
Imagine if this was for a joint bank account where the two
parties are feuding - you've just given access to someone who
has no right to the account.
Lastly, there are usually much better ways to go about these
schemes than questions and answers.
a) if it's to identify someone to a help desk, use a random
number on the screen:
++++++++++++
| Please call 1 800 LUSER, and quote "43743".
b) if it's to recover access to an account, even e-mail or
SMS resets are stronger than this - they are almost a
"something you have, something you know". If you value your
accounts, nothing beats face to face contact. Evidence of
identity is essential for trust in the account.
thanks,
Andrew
On 11/10/2005, at 12:47 AM, Derick Anderson wrote:
What good questions can be used for user verification? I've
seen some
password recovery interfaces which have the typical mother's maiden
name, city of birth, etc. and others which let the user define
their own
question (a stupid idea in my opinion, but I'm willing to be
educated).
I'm thinking beyond a password recovery interface - I'm
more concerned
with a general protocol that could be used in situations where email
isn't an option.
Thanks,
Derick Anderson
