-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Keep email confirmation token on password update. #5951
base: main
Are you sure you want to change the base?
Keep email confirmation token on password update. #5951
Conversation
During `update_user_email` we have to clean up not only chagne email token, but also all tokens that were send to email previously. Such as "confirm" and "reset_password" tokens. This is because they were sent to previous email, which potentially can be compromised at this point, as it can be one of reasons to chagne email initially.
When user decides to change password, mail can still be waiting confirmation. Reason why user changes password is not important and does not lead to any security issue related to email confirmation. So related part of logic is the same for update and reset of password.
Thank you for the PR. Just one tiny correction:
I don't believe there is a security issue here because, when we reset and confirm password, we validate that user email matches the token email. This PR should be exclusively about improving the user experience by not deleting confirmation tokens. All other aspects are protected today. |
To be clear, I believe the PR should only change this line: https://github.com/phoenixframework/phoenix/pull/5951/files#diff-501abec1a66c387cce697c48f3c433e58c4fecd77bcd39765d0f3f982d96c39cL202 And update one of the existing tests. :) |
Previous email tokens are treated as invalid. Protected by email comparison in `verify_email_token_query`.
@josevalim, thanks! I see I missed protection we have by comparison of user emails in Regarding keeping email confirmation token. I think it should be done in both cases "password update" and "password reset". Removing "confirm" email token is inconvenience for user experience in both cases, and I don't see any security issue with keeping token. |
code is actualized with main branch |
When user decides to change password, mail can still be waiting confirmation.
Reason why user changes password is not important and
does not lead to any security issue related to email confirmation.
Logic is the same for update and reset of password.
Covered by tests for update and reset - different tokens are created, and asserted that all except confirm token are deleted.