Re: User verification questions

[Gary Gwin <ggwin () cafesoft com>]

Consider enabling the user to set their own new password on a SSL 
protected form. Then send them an email with a confirmation link with 
embedded transaction tokens that they need to click to activate the new 
password. I've also seen refinements to this work flow where:

1) A cookie is created on the password reset page, that must be present 
in the user's browser when the user clicks the confirmation link.

2) The user must enter a sequence of graphically altered characters (I 
forget what these are called but they have a name) that are displayed to 
them before the confirmation email is sent to prevent brute force attacks.

Gary

--

Gary Gwin
Cafesoft
http://www.cafesoft.com

****************************************************************
*                                                              *
*  Cams is a web single sign-on software solution for Apache,  *
*  Microsoft IIS, BEA WebLogic, IBM WebSphere, JBoss, Oracle,  *
*  and Tomcat web and J2EE application servers.                *
*                                                              *
****************************************************************


Derick Anderson wrote:
> After more discussion we've tentatively decided to send reset (not the
> original) passwords over email to those that have valid addresses, and
> to let those without know during registration that there is no recourse
> for them. Our service is an online job application tool so whatever
> information they lose just gets blackholed. 
>
> Thanks for the input,
>
> Derick Anderson
>
>
> > -----Original Message-----
> > From: Auri Rahimzadeh [mailto:auri () auri net] 
> > Sent: Wednesday, October 12, 2005 8:27 AM
> > To: 'bryan allott'; Derick Anderson
> > Cc: webappsec () securityfocus com
> > Subject: RE: User verification questions
> >
> > Another 2c...
> >
> > Agreed, although I still believe in letting them make their 
> > own question, possibly two (one as a backup). Making it so 
> > they have to initiate communication via the phone or via the 
> > email address they registered with can help. Never call them 
> > with the number they have provided - you don't know if the 
> > email address has been spoofed. If you *do* have to call them 
> > (their email and phone number have changed, for example), 
> > have them verify the questions, but there's only so much you 
> > can do at that point (verify the last four digits of the 
> > credit card they used to pay for the service, and what kind 
> > of card it is, also what their "old" address was).
> >
> > I'm not surprised of course, but most CSRs I call it's easy 
> > to get them to give you hints as to what your authentication data is.
> >
> > Best,
> >
> > -Auri
> >
> > -----Original Message-----
> > From: bryan allott [mailto:homegrown () bryanallott net]
> > Sent: Wednesday, October 12, 2005 4:51 AM
> > To: Derick Anderson
> > Cc: webappsec () securityfocus com
> > Subject: Re: User verification questions
> >
> > 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