Re: Self-Service Password Reset Practices

[Scott Fendley <scottf () UARK EDU>]

The University of Arkansas has had a system like this for about 8
years.  Unfortunately, it was written very specifically to our campus
and the data we have available at our disposal at the time so I won't
be offering it out as open source anytime soon.

We call our reset system, PASSweb.  At the time it was created, we
were just starting to consider using our internal Person ID verus the
SSN that had been used for many years as the defacto
student/university ID number.  So we still allow for SSN, but are
trying to get out of using it for much of anything.  Additionally, we
are preparing to do away with the PIN number we are currently using,
to a system of secure question and answer exchange that you see in
many commercial websites.

On the backend of all of this, we have been attempting to keep track
of account ownerships for the past 10 years.  We by policy stated
that every account would have an owner.  So student organizations,
department accounts, etcetera all have an owner.  Accounts for
faculty, staff, and students are created through an automated system
that involves our student information system and our payroll
system.  All other accounts are entered manually into the account
ownership table as they are created.  The userid and the platform
(which is in essence the server name) are connected to both the SSN
and the university id in this table along with an expiration date
(which is used for automatically locking and removing accounts) and a
project field(which in effect has become more of a way to tell the
type of account it such as student, staff, faculty, student
organization, department, other).

The front end of PASSweb is a secure website which allows you to
select whether you are entering the SSN or the university id, the pin
number used for registration, the system, and the userid needed to be
reset.  It is posted to a secure java program that validates that the
ssn/univ id matches to the ownership of the account, and validates
that the correct pin number was used.  (NOTE: there is an auxiliary
table that we have a few of our super trusted help desk staff can
reset passwords that they do not own.  Also, there are service level
accounts that can never be reset  to prevent someone using the
helpdesk special accounts from resetting root or the admin accounts.)

After everything checks out that you have "proven" who you are, you
are presented a screen where you enter an appropriate password with
our complexity rules to be applied to the account.  There is some
hard coded settings for special systems like our old mainframe who at
one point did not allow for > 8 character passwords and had some
special restrictions on the special characters that were
allowable.  Otherwise, the password is validated and it is submitted
back to this secure server to farm out the password change to the
appropriate system.  This has become easier over time as we have
started moving to LDAP or AD authentication on most of our
servers.  So for uark.edu addresses, you go in and reset the
password, and it updates LDAP (unix side of the house) and AD
(windows side) with the password.  Afterwards, things like your mail
account, dial-up, general access labs, jabber, and samba connections
on the primary unix servers all have the new password in their
reference location.

During the password change, we log what IP, date/timestamp, userid
changed, and the status of the password change.  This information is
useful when you have a ex-bf who decides to reset  the ex-gf's
password to read her email.  And then we get to lecture the victim a
bit on giving out private information to other people.  Additionally,
the date/time stamp gives us knowledge of how old the password is so
that we can comply to state regulations regarding password
aging.  Once a semester we require a password change.  We are
currently evaluating making sure that our users don't re-use
passwords, but that has not been fully implemented.

For those users that have forgotten their PIN number, students must
show their photo ID to staff at the registrar's office who will reset
the pin to month and day of birth, and the user must change it to
something only they know of before the pin becomes valid for any web
application we have developed.  Faculty and staff go to their leave
administrator (which is usually the departmental secretary) who has
the ability to also reset the pin back to month/day of birth.

For the special accounts mentioned above, ownerships are manually
updated with an appropriate audit trail.  So if the owner of the
finance department's email account changes from a retiring faculty to
the administrative secretary, or the department chair, we end up
making the change with paper forms showing the approval and reason
for the change.  From that moment in time, it is up to that owner to
be responsible for resetting the password and administrating the account.

If any user leaves the university, we trigger the changing of the
account expiration date based off of the payroll or the student
information system data.  For those of us that are dual role (student
and staff), when I graduated most of my user accounts had been
created based on my student side of my life.  The lack of student
record caused my student project accounts to be flagged for potential
deletion and i was notified about the future expiration.  Included
are instructions to contact our help desk if the information is in
error so that we can update our information.  At that time, I
contacted the account manager who updated the account ownership
records to reclassify them as staff.  There is always special cases
such as the student who is studying abroad for a semester or a year
that we have to override the standard account maintenance.

The system is not perfect, but it has for the most part worked well
for our purposes.  Hope this helps you see that as long as you have
good data behind the system, then you can do just about
anything.  Just remember that you are going to find special cases in
your organization that will need to have a way to be addressed
procedurally or automatically.

Scott Fendley



At 01:13 PM 7/25/2005, Russ Wade wrote:

> Hello,
>
> We at Wichita State University are in the early stages of
> implementing an Identity Management system.  We will use a single
> sign-on to authenticate access to multiple applications.  This will
> include, in part, SCT Banner for back office and student use.  Our
> email system will use this same sign-on and be equally affected by
> lockouts and password changes.
>
> We are using strong passwords and anticipate a high volume of
> password reset requests.
>
> We are interested in ways others have found practical and secure for
> a self-service password reset function.
>
> We are considering requiring the following information for password resets:
>
>         First Name
>         Last Name
>         SSN
>         Date of Birth
>         Current Mailing Zip Code
>
> We would send an email notification to individuals when their
> password is reset, but their first indication of an intruder
> password reset would be the inability to log on.
>
> Is this generally considered sufficient or do most institutions
> include some additional form of security, such as a challenge question?
>
> Thanks,
>
> Russ
>
> Russ Wade,
> SCT Banner Security Specialist
> Wichita State University
> University Computing and Telecommunications Services
> 1845 Fairmount
> Wichita, KS  67260-0098
> Email:   Russ.Wade () Wichita edu
> Office:  (316) 978-3859
> Mobile: (316) 312-0185
> Fax:     (316) 978-3894