Automated Password Reset

Document revision: 1.3 - 06/17/2003
http://asg.web.cmu.edu/isam/proj/pw-reset

1.0 Background

All Andrew users must have a username and password to login to servers and use many campus resources. If users forget their password, currently the only resource they have is to call the Help Center and request a password reset, which will reset their password back to their University ID, a number that is usually (although not always) identical to the Social Security Number. Every account has a UID associated with the directory entry, and this number can be looked up automatically.

The Help Center requires that the user show or fax his CMU ID card or some sort of picture identification before they will agree to the password reset.

This project is to create a simple web interface to allow users to easily reset their password on their own, taking load off the Help Center.

2.0 Requirements

Initial setup by user must use WebISO for authentication
Initial setup required to enable reset capabilities
Reset request must allow the user to prove identity without using web authentication.
Identification answers will be stored via a one-way encryption mechanism.
Only users who have an LDAP person object with a university ID are allowed to setup/use the system
Password will be set to a user-defined value
The user will have to enter their current password before setting up their account for the password reset tool (there may be pubcookie foo to do this)
The user will have the ability to unsetup their account
The application will email the user when their account is initially set up
Consideration should be given to packaging this for other schools.

3.0 Implementation Guidelines

The URL to the CGI will be off the MyAndrew page, run from a secure CGI web server (one that is running no other services)

This page will only reset a user's Andrew password. It can not be set up for and will not affect accounts for ECE, CS, or any other department. It will not affect local AD passwords.

The CGI will call ADM functions to do the actual password change.

The CGI should use a templating system for site design (talk to blk)

3.1 User Setup

Users will not be able to use this service without first logging in and setting up their account. On future visits, the user may select answers to previously specified questions that will prove his identity with requiring him to log in.

The identification questions may be provided in one of two ways:

Computing Services will require specific information. Possibilities?

Social Security Number (or University ID)
Birthdate

The user may select questions from a suggestion list. Possibilities?

Mother's maiden name
father's middle name
favorite pet's name
favorite unix editor
city of birth
name of first grade teacher
high school mascot
favorite web browser
favorite color

The user will be required to provide non-blank answers for a minimum number of questions (3) to successfully set up the option.

3.2 Data Storage

We will need a secure database to store the information set for each user in the initial login process. Information needed: authorization query, password reset value, personalized question(s)/answer(s).

A local database could be set up on the machine the cgi is running from, possibly either RDB or BDB. Need to see if it makes any sense to put this in ora1 instead

Authorization answers will be stored with one-way encryption.

Authorization answers will be case-insensitive, and all punctuation and whitespace will be stripped. No other canonicalization will be performed. Fields that have a well-known format (e.g. dates) should use a pull-down "fill in the blank" menu.

LDAP will be used for some of the information, since there is already an account for each user with some personal information, including University ID #.

Notes on LDAP usage:

An authenticated user may look up his own (and only his own) UID number

There would need to be a Kerberos principle created so the web page could access the LDAP directory authenticated.

New LDAP attributes would need to be created for each data field to be stored: questions, answers, reset value.

3.3 Security

The CGI for initial account setup will be served off a secure web server.

The password reset page will ask a standard identification question to verify who the reset is being requested for. Once that stage has been verified, the page will display the users's chosen verification questions and be required to give the correct answers before the password will be reset.

The CGI page will use an authenticated Kerberos principle to access the LDAP directory or database to verify the user's answers to the questions.

The new password will be able to be specified by the user on the same screen as the questions. It will need to be entered twice for verification purposes.

3.4 Access Control

Three different classes of people will be given access to this page: alumni, active affiliates, and pre-freshmen. These groups may be given slightly different treatment.

Alumni -- Help message displayed should direct them to contact the Alumni Office, not the Help Center.

If an account has been locked externally for security reasons, the page should recognize the lock and disallow further access. This includes expired kerberos principals.

3.5 Errors

Upon failure, the page should offer further help or exit gracefully.

The user must not be allowed to enter a blank validation answer.
If the user fails the provide proper information to identify a user, they should be given additional chances, with a link to documentation on using the password reset page.
If the user fails to answer their validation questions currently, the page will reprompt them. After a set number of failed attempts (10?), the page MAY lock that account to guard against automated attack or hack, with instructions displayed for further assistance. Logs should also report failed attempts.
A lockout from multiple failed attempts should automatically unlock after 24 hours, or be able to be manually unlocked any time by a generalist.
If the back end password functions fail upon reset, the user should be given a message to try again later.
If LDAP or the question database is down, the page should not be available at all.

4.0 Logging

Logging will be done via DAMS. (via changing an LDAP attribute that will trigger a logging event in dams)

Information logged should include time stamp and IP address for the following events:

Initial user login and setup
Verification attempt (success or failure)
Password reset attempt.

5.0 Stuff we Axed

We considered adding users to an LDAP group as they signed up for the service, but as it would require more permissions for the tool, not be immediately useful, and was easy to regenerate later, we decided to defer it until an actual use was found
If the user is any sysmaint or system group, they must be removed from that group before they will be allowed to go through setup.

really, if we wanted to do this "right" we'd have a bit on some ldap groups that was "this is a high security ldap group" and we'd yank people from that group when they reset their password (from whatever method). At this point we don't think the infrastructure is up to this, but we should consider it in the future
Password will be temporarily set to a random string, and the user forwarded to a password change page.

6.0 Credits

blk did the initial draft. rjs3 got stuck with the rest.
jacquez did the UI work
Lots of stuff taken from the similar work that the University of Washington already did.

Changelog

0.1 - 1/31/2003 - Initial draft
0.2 - 2/06/2003 - Initial draft revision
0.5 - 3/13/2003 - Revision revision
1.0 - 3/20/2003 - Final revision, start production
1.1 - 4/22/2003 - Updates based on further comments.
1.2 - 5/23/2003 - More updates