Re: Self-service password reset approaches

[randy marchany <marchany () VT EDU>]

We've moved away from secret questions. Google "secret question entropy" to
get an idea why secret questions are falling out of favor. Our remote
password recovery options are:

1. Never - the user can opt to not use remote password recovery. Yes, this
means they have to show up in person. Some people like that.
2. SMS text - one time code sent to a pre-registered cell phone.
3. Voice - one time code sent to pre-registered phone.
4. Gmail - reset your password by logging into your Gmail account.
5. Yahoo - reset your password by logging into your Yahoo account.

The user can opt to get an email sent to an (separate) email address when
their password is reset.

-Randy Marchany
VA Tech IT Security Office & Lab

On Tue, Feb 14, 2012 at 9:00 AM, Theresa Rowe <rowe () oakland edu> wrote:

> We are looking at these processes, too.  I am surprised to read Steve's
> response about phasing out security questions and answers.  We just
> implemented this in 2011 and it has been very helpful.  With multiple
> campuses and online learning, we can't expect our constituents to visit
> campus.  We accept a faxed photo identity, along with other security
> information, and will call back with IDs and a pin reset that is forced on
> first login.
>
> Account claiming - specifically providing the student ID number - is our
> biggest challenge.  How are you folks handling that?  We used to have a
> discovery web site, but we were told it wasn't FERPA compliant to display
> student ID like that.  Then we switched the site to email the ID, but that
> didn't work because the individual didn't have access to email if they
> hadn't set it up, and they needed the ID to set it up (catch-22).
>
> Appreciate the discussion -
> Theresa
>
> On Thu, Feb 9, 2012 at 4:53 PM, Steve Werby <steve.werby () utsa edu> wrote:
>
> > Dave,****
> >
> > ** **
> >
> > It’s good to see others considering the progressive approach that other
> > industries have already adopted. Security questions are fraught with
> > problems and put the users’ accounts with other organizations at risk.***
> > *
> >
> > ** **
> >
> > We’ve been designing and developing a system to move from password resets
> > via answering security questions to resets via unique code sent to an
> > alternate email address or mobile phone number via SMS. It’s entirely
> > optional, but since we’ll be phasing out (and deleting) the security
> > questions and answers, the next available disclosed alternative will be a
> > physical visit to an authorized office who will require ID to be displayed.
> > We’re bundling the new process with a change from a typical password
> > complexity/composition policy to a 15+ character passphrase. We’re doing
> > usability testing with a range of users right now and our pilot starts in
> > March.****
> >
> > ** **
> >
> > -- ****
> >
> > Steve Werby****
> >
> > Information Security Officer****
> >
> > Office of Information Security (OIS)****
> >
> > The University of Texas at San Antonio****
> >
> > ** **
> >
> > *From:* The EDUCAUSE Security Constituent Group Listserv [mailto:
> > SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *David Curry
> > *Sent:* Monday, February 06, 2012 8:18 AM
> > *To:* SECURITY () LISTSERV EDUCAUSE EDU
> > *Subject:* [SECURITY] Self-service password reset approaches****
> >
> > ** **
> >
> > It's been a few years since this has come up on the list, so here goes.**
> > **
> >
> > ** **
> >
> > For various administrative reasons having nothing to do with security we
> > need to make some big changes to our self-service password reset approach,
> > and I'm trying to capitalize on the opportunity to improve its security at
> > the same time. At the moment, we do what (we think) many other schools do
> > -- provide student id number, netid (username), and date of birth, and you
> > can reset your password. The problem with this is, of course, it was never
> > that hard to come up with that information in the first place, and the
> > combination of students doing more and more stuff online and the growing
> > use of social media makes it just that much easier.****
> >
> > ** **
> >
> > So... what other approaches are you taking?****
> >
> > ** **
> >
> > There is of course the "pick a few security questions" approach. But it's
> > hard to come up with a set of questions whose answers aren't trivial to
> > guess (either because they have little if any entropy or because the answer
> > is on Facebook). And if you do manage to come up with a set of hard
> > questions, people can't remember what their answers were. Do you use this
> > approach? If so, how have you addressed these problems?****
> >
> > ** **
> >
> > We've been tossing around the idea of using something similar to the
> > "email confirmation" links you see many forum-type websites use. In this
> > approach, we would ask the user for some identifying information (netid,
> > student id number, etc.) and then look up the email addresses we have on
> > file. The user could choose any non-university email address in the list,
> > and we would send a randomly-generated URL to that account, which the user
> > could then click on to reset his/her password. Users for whom we have no
> > alternative email on file (or for whom all the ones we have on file are "no
> > good") would have to call the help desk. Does anybody use an approach like
> > this? How well is it working (or not working)?****
> >
> > ** **
> >
> > Any other "interesting" approaches out there?****
> >
> > ** **
> >
> > Thanks,****
> >
> > --Dave****
> >
> > ** **
> >
> > --****
> >
> > *DAVID A. CURRY, CISSP* • DIRECTOR OF INFORMATION SECURITY****
> >
> > *THE NEW SCHOOL* • 55 W. 13TH STREET • NEW YORK, NY 10011****
> >
> > +1 212 229-5300 x4728 • david.curry () newschool edu ****
> >
> > ** **
>
>
>
> --
> Theresa Rowe
> Chief Information Officer
> Oakland University