We have a private customer support portal, available only to "Verified" customers.
To make that work, Freshdesk recommended that we could simply turn off the Email Notification - User Activation Email and verify customers manually.
This does prevent a person who's emailed in an issue from automatically getting an activation email.
When a user visits the portal url they are asked to log in. As they've not been verified, they cannot. So far, so good.
But unfortunately, if they click on the "forgot your password?" link, they are prompted to enter their email address and are sent a link to set a new password.
Once they do this they are verified.
For this mechanism to work:
The forgot password process should check first to see if the user is verified.
If they are not verified:
- If the User Activation Email is enabled: it should be resent with a new timed link.
- If the User Activation Email is not enabled: the user should be sent a message, configurable by a Freshdesk administrator, informing them of what will happen.
If they are verified:
- The password reset should be processed.
Has this been resolved?
So people can't change password by themself, right?
Sorry but a simple enable/disable for every user may be better, isn't it?
Hi Alessio and Chris,
If you would like to prevent users being able to reset their passwords, You could edit the email notification for Password reset under Admin -> Email Notifications -> Requester Notifications and remove the password reset placeholder and put up a message to reach out to support for resetting the password.
The agents can reset the password for the users manually when the customers reach out.
Having said this, The users will be able to reset their password only if they are verified users in your freshdesk account. Chris, This should solve your concern of new users submitting in the middle of the night. You could turn off "User activation email" under Email Notifications to avoid the user activating themselves.
Please revert for clarifications.
We have a commercial product and our concerns with this problem is competitors being able to gain access by sending an email to support then using forgot password. WE are using Simple SSO from our application to login to Freshdesk. This is an obvious security hole.
We can plug this hole somewhat because we are reviewing tickets. But if someone submits a ticket in the middle of the night by sending an email they can easily use forgot password and get away with whatever they like before we are aware of it.
Is there any work around to prevent this? For me, the easiest feature would be to have an option to disable forgot password for customers. This would be especially true if using SSO. If we aren't using FreshDesk passwords why would it ever be there?
Thanks this fix helps very much but I can't figure out how disable an existing and verified account.
If I change the password user can use the forgot password mechanism to circumvent my block. How can I change this?
This issue is now resolved. Thanks for being patient throughout.
Agents will continue to have access to the forgot password mechanism even if user activation emails are turned off and the agent is unverified. However, a contact will have access to the forgot password mechanism only if the contact is verified.
Please feel free to reach out for any clarifications or feedback.
Firstly, we apologise for the delay in getting this issue fixed. We understand that this should have been sorted out way back and being long pending for about 2 years is definitely not a good thing.
We recently rolled out the Password Policy enforcement and with that we are getting all other breakages and security glitches fixed as well. So yes, we have the best hands working on super high priority to fix this issue as quickly as possible.
We're positive that we will be rolling out the changes within 2 weeks from today. I request you all to kindly bear with us for a few more days and I promise that we wouldn't disappoint you anymore.
Thank you all for being so very understanding and patient throughout.
Have a good day.
Customer Success Manager
I'm sad, really sad
This has been an issue for over 2 years now and this post about it is over a year old. How long will you wait before addressing such a serious security issue??
We need a way to better lock-down access so that a user can not verify themselves and have agents be able to send password resets to the customers.
Having a way to reset passwords from our end would be extremely helpful, both for this issue and in general.
We completely agree with everyone on this topic and definitely have plans to address it on our roadmap.
Unfortunately, I do not have an ETA as of now to promise upon. Sorry about that! Will surely keep you posted.
We need a mode for activate new registration, this not seems properly secure.
This is a problem for us too. On a side note, if you disable the verification emails for requester, is there a rule that you guys have setup for agents to work tickets for manually sending the verification email?
We have the same issue here, we have a private customer support portal too and a lot of customers can activate themself without our activation.
Please let us know, it's a big problem
We ran into this as well - would love a supported way to solve this issue!
I may have found a workaround. Clicking the forgot my password link on the front page sends the requester the Requester Notifications>Password Reset Email message. While you can't disable the notification you can remove the password reset link from the message. This would impact your internal users from resetting their passwords with the link as well though. Any ideas on getting around that?
We have a feature on the roadmap to address this. We'll let you know once that feature is taken up. It should be sometime at the end of the year
...and I'm sure we're not alone...
Thanks for the reply and the explanation. Are there plans in the future to tighten security and correct this flaw?
Since a new customer cannot add themselves to a company, they'll only see what a customer with no company can see. In our case just their own tickets.
So, it sounds like the only way to prevent this security issue at this time is to disable the User Activation Email. Is that correct?