Re: Self-service password reset approaches

[Ryan D Hiebert <ryan () RYANHIEBERT COM>]

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