AWG - Password Reset

Redhat Directory Server - Return from LDAP History

Thu, 22 Sep 2005 15:26:03 -0700

When APU was to deploy our first LDAP directory service, we were looking at running both OpenLDAP and Netscape/iPlanet Directory Server. The sole reason we were going to purchase the iPlanet directory server was because it had a password synchronization mechanism with NT 4. It was a major goal to have a single username and password for all major services running on windows and unix. However, when implementation time came around, we had moved to Windows 2000, which the iPlanet directory did not yet support sychronization with.

Much time has passed...

Password Reset Recommendation Submitted

Mon, 15 Mar 2004 09:34:49 -0800

The Architecture Working Group has arrived at a Password Reset Recommendation.

The [Password Reset Project] will now go back to the Project Management Office, where an implementation team will be established, upon approval from the IMT Cabinet.

There should be enough information to carry out the project in a short timeframe. Some details will be refined during implementation, including an expanded list of security challenge questions to preset to the user. Thanks to all AWG members who contributed their time and clear thinking toward this Self-Service goal. I am sure your feedback will be appreciated as the project moves forward.

Password Reset Recommendation

Wed, 17 Mar 2004 09:37:56 -0800

Overview

In order to provide self-service, and to reduce the volume of support calls to reset forgotted passwords, the Architecture Working Group recommends the following new Password Reset Policy.

Password Reset Steps

User selects "I forgot my password" link on udeupa login page.
User prompted for for:

UID (Username)
APU ID Number
Last 4 Digits of SSN
Correct answer to 2 Challenge Questions*

Submitted data is verified against LDAP and IFAS Database
If verification succeeds, user may reset password in accordance with the password strength policy.
If verification fails, the user is told "one or more of your responses were incorrect", please try again.
After X number of failed attempts the password reset mechanism is disabled for that account, and information is logged.

Challenge Question Initiation

This process change assumes that we re-engineer the challenge question mechanism. Current free-form nature of the challenge question and answer, limits automation. Instead user would need to re-establish answers to a set of fixed challenge questions. This would need to be updated in the registration process. Already registered users will need to be force-prompted to establish answers to the questions one time upon entrance to udeupa. When prompted for a challenge question response, user will be presented with their pre-established questions.

* The user will be able to choose a minimum of two challenge questions, but can optionally choose additional for greater security. All questions chosen will be presented to the user when reseting the password, along with Username, APU ID Number, and last 4 digits of SSN.

Sample Challenge Questions

What city was I born in?
What is my mother's maiden name?
What was my favorite stuffed animal's name?
What was my favorite elementary school teacher's last name?
What was my first pet's name?

For further considerations, best practices, and details to be implemented with this new policy, see Security Concepts and the Appendix.

Which Password Reset Solution Should we Recommend?

Tue, 09 Mar 2004 10:21:42 -0800

[Solution A]

0% (0 votes)

[Solution B]

0% (0 votes)

[Solution C] (A + B)

100% (8 votes)

Total votes: 8

Email Based Resets

Fri, 05 Mar 2004 10:57:35 -0800

One of the things that came up in our discussion was whether or not email based resets are appropriate in our environment. Many sites will generate a temporary hash with a short expire, sometimes after passing a security check (challenge question, etc.), and email that to an address already on file. Arguably, this is an added level of security because the attacker would have also had to compromise the email account as well.

However, our environment is a bit more complex.

As we provide email to our users, the password reset email wouldn't do them any good on that account since it uses the same password.
If the person forwards to an external site, it could perhaps still work. But would that cause security concerns for us to send to a untrusted 3rd party email system? Is the short expire on the hash good enough here?
In theory, we could check to see if they had a forward, before giving them an option to send an email to reset.

Unless the following statements are true, the email password reset would serve no purpose:

Email Password Reset is sufficient enough security, and no additional authentication (identifiers or shared secrets) are required.
Proposed [Simple Solution A] or [Simple Solution B] are not sufficient to allow an immediate reset.

I would argue that both of the above statements are false.

Statement #1

A reset password hash with a short expire is sufficient and convenient for most simple web sites, but 3rd party email accounts should not be trusted for this security context.

Statement #2

Since Proposed solutions A & B, which prompt for secrets which are within our control, are stronger than the untrusted authentication mechanisms of remote email systems, there is no reason to send the users through an additional hoop. It increases the convenience to our users to allow them to immediately reset their password after passing our authentication prompts. There is no reason to send them to an email system, where they receive a http link, that is only going to send them right back to our site.

Summary

Finally, implementing a solution that will not work for all users (not all users forward email), is an unnecessary complication in our quest to produce a simple solution, and in the end would probably confuse users without providing increased security. Even if you believed that the email hash would increase security, since you would have to allow for non email password resets, you have just allowed a weaker form and negated the benefits of the "stronger" form.

Password Reset Archived Work

Wed, 17 Mar 2004 09:28:49 -0800

Historical Discussion of Possible Password Reset Solutions.

Solution C

Mon, 08 Mar 2004 15:51:41 -0800

Option C is Option A & B Combined.

I have a few general comments regarding both solutions. I like that Solution A is pulling data from both IFAS and OpenLDAP. Unfortunately if you found a persons ID card and went on line and paid $20 for their SSN or just pulled it from IFAS you could reset their password. I like that Solution B includes a re-engineered challenge question because this would be the toughtest of all of the data to gather on the person, if the challenge questions are strong enough. I don't like that all of the data can be pulled from one system. My recommendation is a combination of the two solutions. I think we should add last four of SSN to Solution A.

Also, I think we need to add some protection against script attacks. Possibly the random JPEG word entry that ticketmaster.com uses?

-- Darren Flynt

Password Reset Best Practices

Thu, 11 Mar 2004 17:02:26 -0800

Higher Education

Internet2

Internet2 Middleware Initiative's MACE Directory Working Group produced Identifiers, Authentication, and Directories: Best Practices for Higher Education.

Some Highlights from the Authentication section

Use shared secrets or a positive photo ID to reset forgotten passwords.

Shared secrets are pieces of information that users provide when getting their initial passwords. The traditional shared secret is the user's mother's maiden name. Another approach is to have the user provide several pieces of information when first given a password, and then to require the user to provide some subset of this information (say, two items out of five) in order to change the password. Question-and-answer pairs also make good shared secrets.

Non CCCU Universities

Self Service Reset

Saginaw Valley State University - Successful usage of this screen requires the student to know their Login ID, the last four digits of their Social Security Number, the last seven digits of their Student ID (identified on "TheCard" as id #), and their date of birth.
The University of North Carolina at Greensboro offers a Self Service Password Reset, only asking for University ID, username, first, last, and birthdate.
The University of Tennessee has an interesting default password standard which includes some private info. If a password is forgotten it can be reset in some cases back to the default, or web forms are available which ask for University ID and a University Pin. Note, the password reset page is not ssl enabled.
University of Denver offers a Security Question for password resets.

Assisted Reset

Georgetown has a nice print and fax form as the only method for reset.
University of Tulsa requires physical presence with id.
University of Pittsburg requires < href="http://technology.pitt.edu/accounts/">physical presence with id.

Industry

Information Security Mag

An article Password Pain Relief in Information Security Mag, though a bit dated, discusses how several commercial Identity Management products help to establish self-service password resets.

Password-related help desk calls may cost as much as $30 a call, according to a Meta Group study.

PasswordCourier is typical of self-service reset products in enforcing an organization's strong password requirements while obligating the user to authenticate by answering customized challenge questions.

Password reset software generally lets users reset and change passwords from a browser, Windows client or telephone.

In addition to supporting authentication tools, such as tokens and biometrics-either out of the box or through an SDK-self-service reset solutions typically authenticate users through a series of challenge-response questions. These should be questions only the user is likely to answer correctly, such as the name of a childhood pet.

To ensure that challenge questions provide strong user authentication-especially if the questions are the only authentication to the reset tool-reset solutions typically allow admins to define the number and type of questions that must be answered.

Sun One Identity Management

The Sun One Identity Management Administrator Guide explains the Password Reset Service. The service uses challenge questions to authenticate users who have forgotten their password. The only intresting implementation was that the user can select which of the challenge questions to answer when setting them up the first time. This perhaps is an effective way of preventing bad answers, such as "I don't know" etc. Also, there is a feature that can be enabled to write the question as well as the answer. Lastly, they implement good security measures such as lockout.

Sample Questions listed are:

What is your pet’s name?
What is your favorite TV show?
What is your mother’s maiden name?
What is your favorite restaurant?

Appendix

Wed, 03 Mar 2004 09:42:51 -0800

Previous Policies and Other Background information.

Security Concepts

Mon, 15 Mar 2004 09:33:44 -0800

With this project, we are primarily discussing Authentication of Identity. The primary means of verification is through the use of identifiers and shared secrets. A password is really the primary shared secret. So we are really asking for a secondary form of shared secret in case the primary is forgotten and needs to be re-established, or some other identifier.

Two forms fo secondary authentication tokens.

A unique identifier already known to the system and attached to the users identity profile.

APU ID Number
Social Security Number
Phone number or street address (weak)

A shared secret established for the purpose of establishing identity.

A fixed question, such as your mother's maiden name (overused)
A question and answer pair (like our current challenge question)
A set of fixed questions, user supplies answers

It was decided in the first AWG meeting on this topic, that the scope would not include a review of the existing password strength policy. It should be noted, however, that the development of a new shared secret (#2 above) for the purpose of establishing identity, is in essence, no different than a password. To compromise one is to compromise both.

Mitigating Risk

Identifiers

Different identifiers have different levels of inherant risk.

A social security number has quickly become the primary unique identifier for most of the worlds criminal and financial databases. It is the primary target for identity fraud, and is very hard to effectively change. However, as awareness of its importance increases, consumers generally know to protect it. Social Security Numbers are not stored in our LDAP directories making them less accessable to applications for authentication.

An APU ID Number is a university generated unique 9 digit number, similar to a social security number, for the purpose of identifying a person at APU. As its primary purpose is to be a replacement for social security numbers for privacy reasons. Recent government regulations such as FERPA, prevent the use or display of social security numbers in certain contexts. Because it is widely used on campus, printed out on paper on class rosters etc, id cards etc., is somewhat limited as a secure identifier. Psychologically, it is not as protected as a social security number. The ApuIdNumber attribute is stored in our LDAP directory and therefore accessable for wide use in identity and authentication systems.

There are other attributes in our LDAP directory that could be considered identifiers. Multiple phone numbers and addresses associated with a person are stored, and updated via udeupa. These are considered rather weak forms of identifiers, because they are often published in various circles and handed out at the discrimination of the person.

There is a lot of other information stored in our ERP system (IFAS), that could be used to confirm identity. Things such courses taken or previous grades recieved could theoretically be used to verify identity.

One way to mitigate risk with weaker identifiers, would be to ask for several, requiring a user to answer all or some percentage of them correct.

Shared Secrets

Shared secrets are generally established at point of account creation or password reset. They can take the form of fixed questions or free form question and answers.

Generally free form question and answer pairs, such as we currently employed with the Challenge Question & Answer system, are more difficult to automate the verification of because they are more difficult to remember and answer in exactly the same way at a string level.

Predefined questions, while easier to automate, are inherantly less secure because they preset a fixed set of variables. If an attacker knows which question is asked, they can seek out the answer in relation to the target. However, our experience is that persons who develop free form question and answer pairs choose questions and answers that are generally knowable. They will often use things that persons who know them, or can perform research, can determine. In these cases, a fixed set of better questions would be more secure.

Ways to mitigate risk with predefined questions is to establsh several, and then present them to the user randomly. This way the attacker doesn't know which one will be asked. With several questions some level of verification failure needs to be established. More questions means that it is less likely a user will remember every answer. With more questions however, and some level of allowed failure increases the chance of automation succeeding as the user is given a few chances with different questions.

General Considerations

Brute Force Precautions

A time pause betweeen retries should be established to prevent or at least frustrate direct crack attempts.
A lock out should occur if too many attempts fail.

User Notification

It is generally good practice to notify the user that their password has been reset. There is some question about how to notify them, because if their account is compromised such electronic messages would be intercepted. The exception is those with email that forwards to another account, or physical mail.

Auditing

Security should not just be evaluated in terms of preventing breaches, but also in how quickly and intelligently you can respond to incidents. This requires good logging and auditing mechanisms. Whatever solution is developed should log this type of password reset, differently than a normal user or administrative password change. It should include a separate time stamp for this catagory of resets as well. Since the reset will be browser based, the client IP address or other such information would be easy to implement and increase investigative capabilities.

Fall Back

It should be noted, that even though the goal of this process improvement, is to allow for self-service password resets, it is impossible to provide a system that would work 100% of the time for 100% of our users. There will be those, because of technical or other constraints who will still need to contact the support desk. Reasons besides technical scenarios, such as not having access to the internet or an already authenticated workstation, are listed below.

If a user so chooses, he or she should be able to opt out of the password reset option. Challenge questions in particular could infringe on privacy or security desires of users. If they so choose, they should be able to fall back to contacting the support desk, and providing physical or faxed ID.

Certain high level University Administrators, Staff or Faculty, whose accounts pose a greater risk if compromised, could if so desired by policy, be excluded from the password reset mechanism. The same technical mechanism created for the opt out solution previously stated, could be used to handle this feature.

Solution B

Mon, 08 Mar 2004 15:53:25 -0800

Assumptions

This solution assumes that we re-engineer the challenge question mechanism. Current free-form nature of the challenge question and answer, limits automation. Instead user would need to re-establish answers to a set of fixed challenge questions. This would need to be updated in the registration process. Already registered users will need to be force-prompted to establish answers to the questions one time upon entrance to udeupa. When prompted for a challenge question response, user will be presented with one of their pre-established questions in random order.

Steps

User selects "I forgot my password" link on udeupa login page.
User prompted for for UID (username), ApuIdNumber, and answer to re-engineered static challenge question.
Verify submitted data against LDAP.
If passes verification, user may reset password in accordance with the password strength policy.

Questions

Should password be reset to random string, or should user be able to reset to new password of their choosing?
What are adequate Challenge Questions?

Solution A

Mon, 08 Mar 2004 15:52:46 -0800

Assumptions

This solution assumes that we can easily gain access to IFAS data for authentication of identifiers.

Steps

User selects "I forgot my password" link on udeupa login page.
User prompted for for UID (Username), ApuIdNumber, and last four digits of social security number.
Verify submitted data against LDAP and IFAS.
If passes verification, user may reset password in accordance with the password strength policy.

Questions

Should password be reset to random string, or should user be able to reset to new password of their choosing?
Does asking for Social Security Number violate FERPA? (skohrman looking into this).

Current Password Reset Policy

Fri, 12 Mar 2004 16:51:39 -0800

This document lives at https://udeupa.apu.edu/about/standards/password_reset_policy/index.php

The following defines the policy relating to the process of having your password reset in the event that it is forgotten, or expired.

üdeupa password reset order of operations:

Summary:

Challenge Question

Call-Back Method

Visit Support Desk

Self-Service Password Reset

Thu, 06 Oct 2005 11:14:27 -0700

Background

The IMT Cabinet, has requested a change in the way that users reset their passwords. The [current password reset policy], requires heavy interaction with the IMT Support Desk, and is inconvenient for our users. The IMT Cabinet is committed to short term improvements that will enable our long term strategy of Self-Service.

Goal: By Spring II (April) 2004, securely enable a user to self reset their password via üdeupa, after providing sufficient identification credentials electronically.

Password Reset Recomendation Requirements

Best Practices - found within the Industry, High Ed, and specifically CCCU schools
Convenience - simple and efficient process for users
Security - must mitigate risk to an acceptable level
Privacy - must ensure privacy in accordance with FERPA and other laws
Simplicity - a simple solution that can be implemented in a short timeframe without infrastructure changes

AWG - Password Reset

Redhat Directory Server - Return from LDAP History

Password Reset Recommendation Submitted

Password Reset Recommendation

Overview

Password Reset Steps

Challenge Question Initiation

Which Password Reset Solution Should we Recommend?

Suggested Challenge Questions

Background

Logic Related Questions

Email Based Resets

Summary

Password Reset Archived Work

Solution C

Password Reset Best Practices

Higher Education

Internet2

Non CCCU Universities

Self Service Reset

Assisted Reset

Industry

Information Security Mag

Sun One Identity Management

Appendix

Security Concepts

Mitigating Risk

Identifiers

Shared Secrets

General Considerations

Brute Force Precautions

User Notification

Auditing

Fall Back

Solution B

Assumptions

Steps

Questions

Solution A

Assumptions

Steps

Questions

Current Password Reset Policy

Self-Service Password Reset

Background