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?
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.
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.
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:
- Ostrich algorithm: stick your head in the sand and pretend there is no problem.
- 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.
- Implement your own reset flow: Maybe this is the best solution for you.
How to implement your own reset functionality?
- Create a method that generates a random token. Store the random token in a field (user obejct).
- Create a visualforce page that allows users to reset the password in case they provide the correct token as a url parameter.