Educause Security Discussion mailing list archives
Re: Self-Service Password Reset Practices
From: Scott Fendley <scottf () UARK EDU>
Date: Thu, 28 Jul 2005 18:06:36 -0500
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
Current thread:
- Self-Service Password Reset Practices Russ Wade (Jul 25)
- <Possible follow-ups>
- Re: Self-Service Password Reset Practices Lucas, Bryan (Jul 25)
- Re: Self-Service Password Reset Practices Chad McDonald (Jul 25)
- Re: Self-Service Password Reset Practices clementz.7 (Jul 25)
- Re: Self-Service Password Reset Practices Cal Frye (Jul 25)
- Re: Self-Service Password Reset Practices Gary Dobbins (Jul 26)
- Re: Self-Service Password Reset Practices John Kristoff (Jul 28)
- Re: Self-Service Password Reset Practices Scott Fendley (Jul 28)