The 'lost your password' is vulnerable to fishing attacks.
An attacker tries to reset the password of an account, the email gets send out. The attacker needs to check if they can login using this new password. (either by a user clicking the link in the email, or even worse, an automated email vulnerability scanner checking the URL in the email)
To prevent this from succeeding, the following can be done.
The confirmResetPassword class (in Login/controller.php) would need to have an extra check;
After the validation of the resetToken, the user needs to be asked to retype the previous chosen password (used in the initial change your password screen.)
Only after the successful confirmation of this password, the account password needs to be reset.
I'm not a PHP programmer, would this be easy to implement?
Asking the new password in the very first page that can be accessed and submitted by anyone is kind of scary. I think it should only ask an email address (not even a username as it can't be changed) and the resulting page should have a generic message without verifying whether a user for that email address exists or not.
Thanks for the report! Indeed our "Reset password" functionality would be better by having a reset link sent to the email to let the user then reset the password. I think it used to work in this way but i can't remember why we changed it.
or even worse, an automated email vulnerability scanner checking the URL in the email
@RMastop I had not heard that such things exist. Do you know any tool that does this? Clicking automatically in email link is a very broken thing in general and should not be done by any tool IMHO (but my opinion does not matter in this case, agreed)
I think this is quite an important issue as it makes taking over an account too easy if the Matomo user is not careful with clicking on emails (which everyone should be, but no one is all the time).
I agree with @mattab that such a tool would be quite insane and will cause tons of damage with badly written websites, but Matomo shouldn't be one of them :slightly_smiling_face: and fundamentally a GET request should never do an irrevocable action like granting an attacker full access to a Matomo instance.
So at the very least there should be a confirmation page after clicking on the link (correct me if there is already one, I didn't double-check), but I think rewriting this feature to work as on every other website (link allows user to set a new password) will cause less confusion, more security and (hopefully) shouldn't be that much more work.
(feel free to move it to a later release if you disagree)
3.9.0 is already pretty full, earliest we would do this maybe is 3.10 but to be seen. Moving it into 3.10 for now.
Since we wouldn't want to change the whole password reset process, maybe it's good enough to ask for confirmation in a page, before actually resetting password?
Also maybe we could make the link non-clickable in the HTML email body so people are less likely to click on it?
I think asking for confirmation alone will already do 👍
I am not sure if a confirmation page is enough as people can't know what password they are confirming.
link non-clickable in the HTML
That wouldn't help much as most (or at least my) E-Mail clients automatically link URLs.
They would confirm the password they set during the reset process. If someone else meanwhile requested another password, the original link would be invalidated.
If they didn't request the password, we would mention in the confirm etc to only confirm and reset it, if they actually requested it.
asking for confirmation
Sounds like the ideal solution, to ask for confirming the password after clicking the link.
Confirming the password set would benefit a lot, even though I'd still prefer if the password reset would work just like every other website (forgot password -> enter email -> token sent to user per mail -> link to page that allows setting the new password). That way there is less user confusion and fewer ways an attacker can exploit the user confusion for phishing