Re: Self-service password reset approaches

[Theresa Rowe <rowe () OAKLAND EDU>]

We've recently looked at a product that does use the phone to send a
separate code:  Telesign (telesign.com).  Any comments from a current user
out there?

Theresa

On Tue, Feb 14, 2012 at 9:37 AM, Roger A Safian
<r-safian () northwestern edu>wrote:

>  In my mind, there’s no doubt that security Q & A’s are considered
> effective by both the users and the help desk team.  OTOH, from the
> security point of view they are a huge risk.  Especially in education.  Our
> constituents are too young for many questions to be effective, so things
> like “what street did you grow up on?” or “What was your first car?” may in
> fact be the street they live on, or the car they drive, now.  In addition,
> people choose poor questions if they can make their own.  “What color is an
> orange?”  The number of compromises of celebrity accounts shows just how
> risky these questions are.  Personally I’d love to ditch them, but, I would
> need something more effective, and some way to pay for it.  I’d like to see
> something tied to their phone.  Maybe they register their cell, and we sms
> them a temp password.  Not ideal, as people can be overseas, but I think it
> would be safer.****
>
> ** **
>
> *From:* The EDUCAUSE Security Constituent Group Listserv [mailto:
> SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *Theresa Rowe
> *Sent:* Tuesday, February 14, 2012 8:00 AM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* Re: [SECURITY] Self-service password reset approaches****
>
> ** **
>
> 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
>  ****



-- 
Theresa Rowe
Chief Information Officer
Oakland University