Request notifications
1) User tries to log in
2) user fails
3) user is offered a link to recover password
4) Depending on admin settings, user may be shown secret question (which isn't secret, as the user hasn't authenticated yet) and asked for secret answer. Or, user may be asked for first and last name.
5) If available, secret answer is checked. If not, user name is compared to email. If match fails, process stops.
6) User is emailed existing password. Or, depending on admin settings, user may be emailed a newly generated password.
7) (If Q/A admin flag on but user doesn't have Q/A) User is asked for question and answer for "future reference"
There is a second path. Some pages have a link, "I forgot my password."
1) User clicks link
2) User is asked for email
3) Continue with step 4 on first path.
Depending on settings, the user is now emailed either their password, or a link to a page where they are not logged in but do have the power to reset their password.
Drawbacks to this approach:
The logical paths are pretty tangled, making it harder to modify or debug.
Using name as a fallback if Q/A is required but not available is unobvious and insecure
Most of this security is of limited use because the transaction isn't encrypted
The ability to trigger a password reset without fully authenticating is a Denial-of-service vector.
I propose that we remove most of this functionality in favor of:
1) There is an "I forgot my password" link on the failure page after a login
2) If clicked, this causes the password to be emailed to the email on file for that username
3) If the acs-subsite.EmailForgottenPasswordP variable is false, 1 doesn't appear and 2 is disabled.
I believe this is more usable, almost as functional, equally secure, and simpler to maintain and modify.
Opinions?
