Why is challenge-response approach a poor solution for forgotten passwords?

Question

My company is developing an online HR and Payroll application where securing access is critical. I'm clear on how to lock down most of the authentication/authorization processes, except for the 'Forgotten Password' page.

My initial plan was to require the user to enter both an e-mail address and a response to a previously selected/entered challenge question, with a temporary password being mailed to the e-mail listed (assuming the e-mail is valid). But I've read here and here (both on SO) that the challenge-response approach is insecure.

If we're only e-mailing a temp password though, is it really that insecure? The only more secure option I can think of would be to require the user to call their Customer Service Rep, which would greatly burden our employees.

What am I missing ... is there a better approach? Thanks!

Answer 1

Don't email a temp password, email the user a URL+token to a reset-password page. That way no password is ever changing hands unencrypted. It's also immediately obvious to the end-user that their account has been compromised if they try to go to that page and the reset token has already been used.

Added from the comments:

I think challenge-response ("secret question") aspects actually make things less secure, because they are generally things that can be discovered by researching public info about the target. The fewer steps total, the fewer that can be broken without anyone knowing. Letting reset emails go early and often is a good way to let a human know the attempt is being made.

Answer 2

As explained in this article, Governor Palin e-mail account was recently hacked using answers to previously asked questions. From the article:

As detailed in the postings, the Palin hack didn't require any real skill. Instead, the hacker simply reset Palin's password using her birthdate, ZIP code and information about where she met her spouse -- the security question on her Yahoo account, which was answered (Wasilla High) by a simple Google search.

Answer 3

Wouldn't it be easy/feasible to outsource the whole password management just like SO did and use OpenId or similar? Of course this would add another dependency, but you'd trade that against the need to save (and secure) passwords and deal with them as you described.

Answer 4

You said it is an on-line HR and payroll application. Do you have the option of a user indicating he/she has forgotten his/her password and that generating a message to an HR representative or some official in the organization who can confirm identity and then issue a password reset?

Answer 5

There are a few common ways to manage lost passwords:

• The Secret Question: It is actually a weaker form of authentication, just like people above posted. User may choose something really simple and it is easy to guess. I advise against this, because it does not require any technical "hacking"

• Mail a new password. To circumvent this control, access to the e-mail account is required or a Man-In-The-Middle (MITM) position is required: You either read the temporary password from user's inbox or intercept in the middle. This approach is ripe for misuse, because anybody can reset the password and force the user out of the system, if he can't read the e-mail with new password.

• Mail a password reset hash, to circumvent this, you need access to inbox or MITM, just like in case before this, but no passwords are actually reset until confirmation is done. Thus, user can not be locked out of the system, even if he did not read the e-mail. Add a cooldown timer to one reset per 8 hours to prevent Your system from flooding user's inbox.

• Consider some out of band communication, for example, in the printed contract, write down a PIN. Then have the user call Your helpdesk from a known phone number (check with Caller ID) and give his username and PIN.

Answer 6

In short, challenge questions are often the weakest link. They're easier to guess than a password and effectively operate as a proxy for a password, so they actually reduce security rather than enhance it by providing another attack vector that's actually easier to break. The Web Application Hacker's Handbook has some great information on this area.