Re: Self-service password reset approaches

[Nathan Zierfuss <nathan.zierfuss () ALASKA EDU>]

We use two parts similar to what Ryan described. There is account claiming
and password resets. In claiming the individuals account exists but they
don't know the password. They vet themselves based on information they gave
the institution in the admissions process that are now part of their
student record. Currently this is used for password resets as well but we
are shifting to allowing users to set 3 security questions after the
vetting process. For resets they would now need their username and piece of
personal information, such as a birth date, and after verifying that
information they see 2 of there 3 questions they choose and provided
answers for. If they get them right they can reset their password. If they
fail they get one more opportunity, this time with the question previously
unused as one of the 2 presented. This is the last try. Success and failure
messages are sent to all email addresses on record for the individual. If
the individual does not have 3 security questions set they are forced back
to the vetting process used for account claiming. If an individual has
elected to place a FERPA directory hold on their student record for privacy
reasons, the account does not exist or they fail to vet the self-service
interface prints a generic helpdesk contact information page that is the
same for all those scenarios.

One condition with regard to the challenge/response questions is the
response can not be in the challenge. So "What color is your blue car?"
with the answer "blue" is not allowed for list selected questions or user
provided questions.

The helpdesks have no ability to set passwords for accounts. They can
administratively set challenge/responses for an account but the user must
use them to gain access to the self-service reset tool then select new
challenge/responses and reset their password.

Because the password they are trying to reset gets them access to their
institutional email account and distrust of any email addresses they give
us from other providers sending an email with a url or code to reset the
password was not a viable option for us.

Nathan

On Mon, Feb 6, 2012 at 10:07 AM, Ryan D Hiebert <ryan () ryanhiebert com>wrote:

> We are considering implementing something like that as well.
>
> The two parts we are considering are account creation, and password reset.
>
> For account creation, the new user will need to identify themselves by
> some meaningful combination of name, id number, social security number, and
> birthday. It is true that this could be done by someone other than the
> individual themselves, but we expect that issues that will arise from it
> will be able to be handled manually. Once identity is confirmed in this
> manner, we require them to give us a valid external email address, to which
> we will send a password reset link, which will activate their account.
>
> The password reset will reuse the email functionality from the account
> creation process, except that the user will not be allowed to specify an
> email address, since one should already be on file for the user.
>
> Users without external email addresses on file would have to call the help
> desk.
>
> We haven't implemented it yet, so I can't give any feedback on how well it
> works.
>
> Ryan
>
> On Feb 6, 2012, at 6:17 AM, David Curry wrote:
>
> 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


-- 
Nathan Zierfuss, CISSP, Information Security Officer
-
Technology Oversight Services, University of Alaska
910 Yukon Dr. Suite 105, PO Box 755320
Fairbanks, Alaska 99775-5320
-
Phone: 907-450-8112  Fax: 907-450-8381