yes, creating your own question/password i find is quite tiresome
sometimes...
they are not designed to be secure [nor are those public-knowledge run of
the mill questions maiden name etc.. privacy issues aside] and herein lies
some of the problem. by calling them security questions to start with sets
up a whole bunch of expectations which are not valid.
and same applies to creating your own "security question"...
due to volume/entropy, i sometimes end up forgetting how i answered my own
question over time [the converse applies: if i forgot my password, chances
are i forgot my own question/answer :)]
in which case, i've ended up creating a question which never changes and can
only be answered one way: "where were you born?" aahh the irony!
it also puts a lot of pressure on the user to think up, what they deem to be
"secure", if that is the instruction... alarm bells started ringing yet?
but like u say, they're not concerned with security, they're concerned with
memory. what will i never forget if i do forget my strange password? aahh!
i'll never forget my mother's maiden name :) it's the easy way out and
they've probably been conditioned already by previous experience on sites
where the questions are already provided- so choose something u know rather
than spend half hour of trying to be creative.
a tricky situation.
lockouts, encryption and a support call OR email. let the user decide what
they would be comfortable with? then let the users tell u what they're adept
at. maybe over time the'll all start to learn how to use email :)
----- Original Message -----
From: "Derick Anderson" <danderson@vikus.com>
To: <webappsec@securityfocus.com>
Sent: Tuesday, October 11, 2005 7:01 PM
Subject: RE: User verification questions
The problem I have with users creating their own questions is that they
aren't concerned with the security of their question. Perhaps if they
were required to remember the question as well... but if they can
remember a question and answer they probably won't forget their
password.
Asking for usernames and passwords over the phone seems a little like
reverse social engineering, although I suppose since they are the ones
calling us the danger is minimal at worst.
As for lockouts and encryption I think that is good practice in general
which I have been pushing where I work. We collect SSNs because it is a
job application. The risks of providing one online are similar to those
of providing one on paper. Whether it is good practice for us as a third
party to have access to those SSNs is another story.
Derick Anderson
-----Original Message-----
From: Auri Rahimzadeh [mailto:Auri@auri.net]
Sent: Tuesday, October 11, 2005 12:18 PM
To: webappsec@securityfocus.com; Derick Anderson
Subject: RE: User verification questions
While not a be-all-end-all approach, I've implemented the
following on a few sites:
* Let the user create their own question/answer.
* Do not email usernames and passwords - require the user to
call and verify information (with no disclosure or hints).
* Lock out invalid login attempts for minutes at a time to
prevent brute force attacks.
* Encrypt all the personal+confidential data in the database
and encrypt+hide the keys.
I question why you'd collect SSNs BEFORE an applicant has
been hired. It seems unnecessary and dangerous to store along
with so much other personal information.
Best,
Auri Rahimzadeh
Author, Geek My Ride
Author, Hacking the PSP
Co-Author, Hacking Digital Cameras
---------- Original Message ----------------------------------
From: "Derick Anderson" <danderson@vikus.com>
Date: Tue, 11 Oct 2005 12:00:47 -0400
>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
>> >
>> >
>> >
>> >
>>
>>
>
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.14/128 - Release Date: 10-Oct-05
