Historical Discussion of Possible Password Reset Solutions.
This solution assumes that we can easily gain access to IFAS data for authentication of identifiers.
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.
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
Everyone seems to agree that challenge questions provide an small increased level of security over simply asking for known identity information as in [Solution A]. It provides a bit of randomness that would otherwise be missing if we only asked for udeupa username, ApuIdNumber, and partial social security number. The only problem is that some questions which promote more random answers, will be more difficult to verify, and will be harder for users to remember. In other words, we don't want to ask really simple questions, but we also don't want to ask a question that can be answered in a thousand different ways.
If the goal is to reduce the overhead and inconvenience of password resets through the support desk, by providing an easy to use self-service tool, then challenge questions could present a some problems. The key will be to decide which questions to ask, and the method of verification. It may become burdonsome as well to ask too many questions. Remember if the user doesn't remember any of their answers they will be calling the support desk.
With these considerations in mind, it can be understood why questions such as "mother's maiden name" are so widely used. Its something you won't forget. Its something that is a single word and spelled the same way every time. These things help verification. This is not a promotion of this question, but rather an example of the attributes that probably make it a good challenge question, if viewing it from more than just a security perspective.
Remember we aren't shooting for the ultimate solution, if we were we wouldn't be using passwords at all.
Please attempt to answer these questions, and provide suggested (even if duplicated) Challenge Questions below.
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.
Unless the following statements are true, the email password reset would serve no purpose:
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.
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.