Forgot Password: Verification Link before reset

[Forshock]

Forgot Password autmatically resets the password of the user and does not require verification of email access.
This can be used to lock other users out by malicious actors.

Like the signup verify, allow for email verification before resetting the password.

[Forshock]

Additionally, changing the process for resets to limit User Enumeration attacks. Always send to "If account exists you will receive an email.

https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

[instantflorian]

A two-step-verification for restting the password is a good idea, not sure how to implement this.
But giving no exact feedback imho does not really enhance the security very much (a attacker just tests a bulk of mailadresses, and needs access to that mailboxes anyway to recieve login credentials), but real users will be confused, because they wont't know if they had entered the right mail address or not. Also for fixing technical issues it's important to know whether a mail should have been sent or not. So I suggest to leave the message as is.

[WebDesignWorx]

I'd rather leave it as is.
The only scenario I would bother with this issue is in the event when WBCE users start complaining about it. But so far I haven't heard from anyone.

[mrbaseman]

Well, we assume that the email addresses are correct in the database. We could implement a verification process in the context when accounts are created or email addresses are changed. The verification link for the changes should expire after a reasonable time span... There are a couple of details to evaluate carefully.
Anyhow, in the context of a password reset one could argue that it's already too late to do the verification of the email address. If the attacker has already control over the inbox of this email account, he also receives the verification link. If not, he doesn't receive the new password either.
In my opinion we can improve in the following aspects:

• add a note that the changed password, which has been sent by email, should be changed once more interactively by the account owner
• If the email exists, we could change the process such that the password change is postponed and send a link instead, which allows to interactively change the password for a given account, and which is valid for a limited time. If the email doesn't exist, I agree with @instantflorian a clear error message really helps for analyzing problems.
• against user enumeration there is a captcha check already in place, and the attacker needs to know the registered email addresses in advance (ok, this might be trivial, depending on the page content of some websites, so perhaps we should add a hint in the backend not to publish the email addresses used for registration on the website itself?)
• We could extend the brute-force protection of the login page to the password change page as well. This might be quite easy to implement, because a password change could be treated similar as an event of entering the wrong password. For legitimate changes, there shouldn't be any impact, but if someone tries to change lots of passwords, his source IP gets blocked for some time. At least an idea to think about.

[Forshock]

After digging in a little, the existing signup confirmation process may be useful to process the request.

On signup the confirmcode and checksum are created (and updated). (account/confirm.php)
User clicks link and a new random password is sent.

The only portion that may need change is in the account tool (tool_account_settings/account/form_forgot.php)
Rather than change the password, the code & checksum are updated, and a new verification link is sent.

[Forshock]

And since I am referencing tool_account_settings: I cant find an explanation, but how is this a module when it is part of core functions? Would it not make more since to be within the framework? (New to this level of interaction on an open-source project so please forgive me if already mentioned or explained.)

[WebDesignWorx]

It is a module because sometimes people want to make changes to the functionality of this part of the CMS and rather than letting them do in in the core part we decided to make it a module.
Also, you can reach the templates/layouts of the login/account etc. using 3rd party tools like the AFE, something you couldn't otherwise.