20

In most SaaS password reset flows, the actual reset of the password does not occur until the user clicks on a link received via email. This link prompts the user to enter a new password. (Salesforce, for internal users, takes the extra step of asking the user to answer his security question.) If the user doesn't ever click the link in the email, the existing password remains intact.

The password reset flow for a Community user is different, and not in a good way: as soon as the user clicks on the button after entering her email address/username in the form, the password is reset to some unknown value. In other words, the user is completely unable to login until clicking on the link sent in the email.

This means that, in a Community, someone with knowledge of usernames/emails (someone else in the Community?) could come along and reset everyone else's password. Not a big security threat, since that email link is required to actually get a new, known password, but a major possible UX disaster.

Am I correct in my diagnosis, and is there a way to make Communities password reset behave more like the flow I outlined in the first paragraph?

Improve this question
5
  • Can't you modify the controller logic in Apex? Perhaps to send an email with a link that then performs the reset...
    – Matt and Neil
    Dec 18, 2014 at 23:08
  • The problem there is that Communities don't use the regular "forgot password" page and controller. They use some kind of stock jsp page. I could of course create my own forgot password page/controller, but that's reinventing the wheel a bit, and it'd be pretty involved managing the security of password resets. Would be nice if it were stock.
    – Matt Welch
    Dec 19, 2014 at 1:50
  • Let me amend my previous comment. You CAN use the "ForgotPassword" page and it's controller, and it provides the Site.forgotPassword class/method to affect the password reset. (We've gone the extra mile and checked validity of the username, so the user gets a message as to whether a reset actually occurred.) My original problem still exists, though: the reset happens instantly.
    – Matt Welch
    Dec 19, 2014 at 16:44
  • 5
    Sounds like something to post in the Salesforce Ideas Community
    – crmprogdev
    Dec 22, 2014 at 19:21
  • You can implement your own reset scheme - send an email with link and use it to execute site.changePassword.
    – dzh
    Sep 7, 2015 at 9:37

2 Answers 2

Reset to default
3

I agree that the password reset flow in salesforce is not ideal. During the last 7 years the way "Networks" (former name portal, today communities) has been changed multiple times.

At the beginning salesforce was sending out passwords in the welcome mail. But it was possible to suppress the standard message. I was sending my own mail instead.

There can be several reasons why the password rest flow is not optimal.

The Site.forgotPassword(username) method is described as:

Resets the user's password and sends an email to the user with their new password. Returns a value indicating whether the password reset was successful or not.

The Method System.resetPassword creates a new password.

It seems like the concept of "rest password" is interpreted as "reset password now".

Anyway, you need a solution for this issue and here are 3 different approaches:

  1. Ostrich algorithm: stick your head in the sand and pretend there is no problem.
  2. Use an external authentication provider: Replace the standard login and password reset functionality with SSO. A different system has to deal with the issue of password rests.
  3. Implement your own reset flow: Maybe this is the best solution for you.

How to implement your own reset functionality?

  1. Create a method that generates a random token. Store the random token in a field (user obejct).
  2. Create a visualforce page that allows users to reset the password in case they provide the correct token as a url parameter.
Improve this answer
2
  • For your "own reset flow" - you're creating a security hole with that reset URL unless you have a process to invalidate that token. E.g., it's good for an hour or a day, whatever your policy would require. Additionally, it would be stronger to use a 1 way hash to encode that token when you persist it so that it's not laying around in plain text.
    – Bobby White
    Jun 3, 2016 at 15:36
  • '"Networks" (former name portal, today communities)' ... now called "Digital Experiences" (rolls eyes).
    – Frans
    Apr 20, 2021 at 11:30
3

Based on my recent tests on Spring '16 release, the standard Forgot Password controller sample uses Site.forgotPassword(username) and calling that method will send a reset email with a link, but the old password is still valid.

At some point, the behavior of Site.forgotPassword has been changed to stop invalidating the existing password.

Improve this answer

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.