2

I am creating an application where the user will be able to recover their password from a "forgot password?" link. Once the user clicks on the link they are presented with their recovery questions which they would have filled out during the account registration process. If they were to fill out the questions correctly they receive an e-mail with a new temporary password which they would update upon logging in.

My issue is on the recovery question screen. If the user cannot remember their recovery questions is there a best practice on a way to allow the user to reset their questions without getting their password first?

We are thinking it may have to become a customer support issue where the user would have to call in for a recovery question reset, but I find that inefficient and inconvenient for both the user and the support team. Is there a process that anyone is aware of that could solve this issue and allow the user to reset their recovery questions which in turn would allow them to reset their password.

4

I have wrote a couple articles on this subject (in Spanish). The obvious answer would be: use multi-factor authentication. I really despise that approach. In those articles I have demonstrated with real user cases that they're not necessarily more secure, but they always lead to HORRIBLE user experiences.

Without getting into great detail, let me put it as simple as this: if you want to perform an action on your device and you're asked to perform additional actions on a different device, you're breaking most UX heuristics. As simple as that. Maybe it's more secure, but usability will be a nightmare (simple case: what if you don't have another device at hand?)

Other approaches

The safest, most secure and most usable way is to allow users to use keys and recovery questions they will actually be able to remember. If you need your users to write down their access information, then security will be severely compromised. Yet, security questions on most systems have became so crazy most users will need to write them down!

Check the image below:

enter image description here

the stupidly easy to remember pass is almost impossible to break. The supposedly good one would take 3 days. Assuming the user remembers it!

The usability and CX angle

As you correctly said, this could become a real burden on CX. You'll need to apply more effort and more people for a problem that should never have existed! But this is not the only problem: if as an user, I need to contact customer support or ask for a new password every time I log to my account, it's just a question of time before I stop using the service

Don’t Make The User Feel Stupid: A Lesson In User Experience

The point: if a customer is unhappy with a product or a website, you’ve lost them. You can’t get them back with this approach, because it just makes them feel stupid. Customers want to buy a product and me done with it; if it turns into a long, drawn out experience that requires too much support, that’s a product they will never be happy with.

So... what to do?

This will entirely depend on you and your setup, but I'd recommend the following tips:

  • Actions should be performed on the same device. Always. No exception.
  • If an user has to call you to perform even the simplest action (eg: entering your site, doh!)... you're on the path to lose her
  • Allow to re-use passwords. There's a reason why users chose them in the first place.
  • If you use recovery questions, make them really easy to remember. I really have to make an effort to remember my first school name, or my first pet's name (was a dog, a cat?). Instead, offer the user to create their own answers: "please create a security questions whose answer is known only to you"
  • Use automation. If you identify the device and location go easy on that one, a "request new password by mail" should be enough.
  • Users never complain about security. The only ones that complain are the stakeholders, mostly based on urban legends
  • Weigh the pros and cons. Assuming an user's account is affected... what's the worse that could happen? Is there any sensitive data? Or is it just "Facebook like" stuff?
  • Once you do the above, weigh how the usability of the system will be affected
  • At all times, remember: security is your responsibility, not your users' fault!
  • 1
    I very much appreciate your insight. I am trying to make this as painless a user experience as possible. As I analyzed the problem myself, I also agree that it is going to be a must to make sure the recovery questions are easy to remember to the point where they do not need to be written down. As much as I would like to get away from recovery questions that is where my hands are tied as we will have sensitive data that needs a good security/authentication system. I will just sacrifice a few UX niceties in honor of security. Marking as answer. – Nick_M Jul 26 '17 at 20:41
  • 3
    "Use automation. If you identify the device and location and password is close to the correct one, or if user had an obvious typo, go easy on that one." From a security perspective this is terrible advice. If you can tell that the password is "close" to the real one, then you are storing password as plaintext or reversibly encrypted, both of which are very bad things. Passwords should always be stored as a one-way hash, so the original password cannot be recovered in the event of a data leak. – Craine Jul 27 '17 at 14:27
  • possibly. I'm not an expert in implementation, so sometimes good usability "earns me" over good practices on other disciplines. I have seen this kind of behavior before, so guess the systems doing this were doing something not very secure, now that you mention it. Anyways, my point is: "security" has gone bananas and made most experiences awful without any real need – Devin Jul 27 '17 at 15:08
4

The problem with Security Questions

While it may seem that security questions are something that you'd want to implement in your application to provide an additional layer of security, you aren't really adding anything of value to the security of your user's accounts. A study by Google showed that across their very large user base, security questions were largely ineffective at providing additional layers of security, because answers were either:

  • Forgotten

    Question memorability decreases significantly over time. For example the success rate for the question "Favorite Food?" is 74% after a month, 53% after 3 month and barely 47% after a year (Section 4.2).

  • Answers were publicly available

    Publicly available answers. Rabkin found that 16% of ques- tions had answers routinely listed publicly in online social- networking profiles [27]. Even if users keep data private on social networks, inference attacks enable approximating sen- sitive information from a user’s friends [24]. Other questions can be found in publicly available records. For example, at least 30% of Texas residents’ mothers’ maiden names can be deduced from birth and marriage records [15].

  • Answers were statistically common enough they could be guessed quickly

    Statistical attacks against secret questions are a real risk be- cause there are commons answers shared among many users. For example using a single guess an attacker would have a 19.7% success rate at guessing English-speaking users’ an- swers for the question "Favorite food?" ... With 10 guesses an attacker would be able to guess 39% of Korean-speaking users’ answers to "City of birth?" (Section 3.1).

Additionally, if you suffer a data breach, and the answers to the questions leak, you're in for a heap of bad press (quote from wired.com article below):

"Sorry, but if you have a Yahoo account, you will need to find a new mother, and have grown up on a different street," University of Pennsylvania computer scientist Matt Blaze quipped on Twitter after Yahoo's data breach announcement.

A better UX solution

Since you are already relying on the assumption that a user must have access to their registered email address to reset their password (by sending them a temporary plaintext password), you are better off nixing the security questions altogether, and move to a token based reset process. To the user the password reset process should look something like this:

  1. User forgets password, and submits email in forgotten password form
  2. User gets email with a password reset link
  3. User clicks on password reset link and is presented with a password reset form
  4. User enters new desired password in form and submits
  5. User logs into application with new password

On the backend, your application should do the following:

  1. When a user submits a "forgot password" request:
    a. Application generates a random token and an expiration timestamp and stores them in the database
    b. Application sends an email to the user with the random token and account identifier (email or id, for example) in the reset link as URL parameters
  2. Account identifier and reset token are placed into hidden form fields on the reset form
  3. User submits reset form: a. Application checks that the reset token matches the one stored in the database for that specific account identifier b. Application checks that current time is not after the expiration timestamp for the reset token c. Application hashes the submitted password and stores it in the database d. (optional, but good practice) Application stores a timestamp and other identifying information on the request that submitted the password reset

From a user's perspective, this is a much more usable system. They only have to know the email address they registered with, and the technical security of the reset process (time-bound, long, randomly generated reset tokens) is abstracted away into something they don't need to interact with. You are better off because you are storing less personally identifiable data (a concern with GDPR coming in force next year), you don't need to have users contact customer service to try to identify themselves another way.

If account security and additional verification are big concerns for you, then you should take the time to implement a second, out of band verification, such as a recovery email address or phone number for SMS delivery of a second token.

Additional reading:

Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google - Google
Time To Kill Security Questions — Or answer them with lies - Wired
7 Reasons Why Password Recovery Questions Are Worse Than Useless - Dashlane

1

Send OTP on registered mobile number or recovery email id that was used at the time of sign up process. You can ask the user to select one of the options from the above.

I agree with Devin points

If you use recovery questions, make them really easy to remember. I really have to make an effort to remember my first school name, or my first pet's name (was a dog, a cat?). Instead, offer the user to create their own answers: "please create a security question whose answer is known only to you"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.