-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reuse password reset tokens until they expire #25280
Reuse password reset tokens until they expire #25280
Conversation
This avoids a race condition where email delivery is slow and user generates new token before original (now invalid) token is received. This also avoids giving an attacker a stream of sequential tokens, reducing impact of any information which might be leaked about the random number generator's state
Hi @fredden. Thank you for your contribution
For more details, please, review the Magento Contributor Guide documentation. |
Hi @fredden. Thank you for this contribution, however we've had the discussion with the product owner on security track and it was confirmed that token regeneration is the expected behaviour here. Unfortunately I need to close this PR. Thank you. |
Hi @fredden, thank you for your contribution! |
@lenaorobei Where/how can I participate in such discussions? This change introduces a much better user experience with minimal real-world negative security impact. Eg, https://www.youtube.com/watch?v=-gpfKW_8EJw |
Hi @fredden. Thank you for your contribution
For more details, please, review the Magento Contributor Guide documentation. |
Update: on 15th April I reached out to @lenaorobei on Magento Community Engineering Slack instance, who helpfully set up an open conversation with "the product owner." That conversation is here, but as yet (23th April) there is no response from the product owner. |
Update: product owner suggests another approach which has the same benefits achieved here. I will update the code to match this method.
|
@magento create issue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @fredden,
We're really sorry for long delay with processing your PR. I'll take your PR and will try to push it forward.
Could you update your solution according to requested changes from PO?
#25280 (comment)
Hi @ihor-sviziev, thank you for the review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @fredden
Thank you for your contribution
I'm not able to reproduce the original issue on the latest 2.4-develop
I have generated a password reset e-mail, did not use it. Waited for the link to expire
Checked the token in dev console Elements
And the token in the link while redirect page is loading
Then, I have created another Reset password e-mail for the same user (also tried with a different user), the token is different.
@engcom-Bravo I believe the problem here is that you've waited for the link to expire. Expired links should not be restored, but links that have not yet expired should have their validity extended. |
Hi @engcom-Bravo, |
Moving back to "ready for testing" as we got an answer from the author of this PR. |
@magento run Functional Tests B2B, Functional Tests EE |
@magento run Functional Tests B2B, Functional Tests EE |
@magento run Functional Tests B2B, Functional Tests EE |
Hi @fredden, thanks for contributing! We have discussed this issue at public triage meeting and EngCom team and contributors that were present agree that we should not reduce security (keeping the link valid) for a better user experience. Also, we agreed that the way that this feature works is a standard in the market, pretty much all other platforms or services have this practice. I will be closing this PR for now, but please, feel free to reopen it and we can discuss it further if you like. Thanks! |
Hi @fredden, thank you for your contribution! |
Description (*)
This avoids a race condition where email delivery is slow and user generates
new token before original (now invalid) token is received.
Consider the following scenario:
This also has the added bonus of not giving an attacker sequential tokens upon request. While the tokens are understood to be suitably opaque, any information disclosures identified in future will be at least partially mitigated by reusing the same token rather than giving out another token data point.
Fixed Issues (if relevant)
Manual testing scenarios (*)
Questions or comments
I am unsure if this change requires a unit test.
Contribution checklist (*)
Resolved issues: