XWIKI-21571: Change default value of the reset password token lifetime #3012
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change the mechanism of the reset password token to not reset it at each verification code check, but only when the password is actually reset, and when its lifetime expired. Also provide a mandatory document initializer for the ResetPasswordRequest xclass.
surli
added
the
backport stable-15.10.x
Change a bit more the logic: if the token lifetime configuration is set to 0 (which was the default) then we automatically remove the reset password request xobject at first wrong attempt (bad verification code): it will prevent any bruteforce attack. Then if there's a token lifetime configuration set, we don't remove the xobject when a bad attempt is performed: user might have used the wrong mail for example. But we do remove the xobject when it's expired. And if it's expired, or if the code was wrong, in both cases we immediately return an error.
Move ResetPasswordIT and ForgotUserNameIT from administration-test-docker to a new module security-authentication-test-docker since it's related to security-authentication module now.
* Update the property documentation
* Ensure to properly set the user before update config in integration
tests
manuelleduc
reviewed
Mar 26, 2024
| } | ||
| } else if (userInformation.userExists && userInformation.userEmail == null) { | ||
| // In case the mail is not configured, we log a message to the admin. | ||
| this.logger.info("User [{}] asked to reset their password, but did not have any email configured.", |
There was a problem hiding this comment.
Shouldn't this information be communicated to the user requesting for a password reset?
There was a problem hiding this comment.
Note that I haven't changed the behaviour here, it's just that the diff is not easy to read. So I don't want to change that now. AFAIR we decided to always display the minimum of information when trying to reset a password so it basically always say the same thing to prevent any kind of data leak.
We could decide to change that but IMO it deserves a dedicated ticket.
manuelleduc
reviewed
Mar 26, 2024
...lt/src/main/java/org/xwiki/security/authentication/internal/DefaultResetPasswordManager.java
Outdated
Show resolved
Hide resolved
manuelleduc
reviewed
Mar 26, 2024
...org/xwiki/security/authentication/internal/ResetPasswordRequestClassDocumentInitializer.java
Show resolved
Hide resolved
…urity-authentication/xwiki-platform-security-authentication-default/src/main/java/org/xwiki/security/authentication/internal/DefaultResetPasswordManager.java Co-authored-by: Manuel Leduc <manuel.leduc@xwiki.com>
* Add missing since
github-actions bot
pushed a commit
that referenced
this pull request
Mar 27, 2024
#3012) Change the mechanism of the reset password token to not reset it at each verification code check, but only when the password is actually reset, and when its lifetime expired. Also provide a mandatory document initializer for the ResetPasswordRequest xclass. Change a bit more the logic: if the token lifetime configuration is set to 0 (which was the default) then we automatically remove the reset password request xobject at first wrong attempt (bad verification code): it will prevent any bruteforce attack. Then if there's a token lifetime configuration set, we don't remove the xobject when a bad attempt is performed: user might have used the wrong mail for example. But we do remove the xobject when it's expired. And if it's expired, or if the code was wrong, in both cases we immediately return an error. Move ResetPasswordIT and ForgotUserNameIT from administration-test-docker to a new module security-authentication-test-docker since it's related to security-authentication module now. --------- Co-authored-by: Manuel Leduc <manuel.leduc@xwiki.com> (cherry picked from commit b410dad)
surli
added a commit
that referenced
this pull request
Mar 27, 2024
#3012) Change the mechanism of the reset password token to not reset it at each verification code check, but only when the password is actually reset, and when its lifetime expired. Also provide a mandatory document initializer for the ResetPasswordRequest xclass. Change a bit more the logic: if the token lifetime configuration is set to 0 (which was the default) then we automatically remove the reset password request xobject at first wrong attempt (bad verification code): it will prevent any bruteforce attack. Then if there's a token lifetime configuration set, we don't remove the xobject when a bad attempt is performed: user might have used the wrong mail for example. But we do remove the xobject when it's expired. And if it's expired, or if the code was wrong, in both cases we immediately return an error. Move ResetPasswordIT and ForgotUserNameIT from administration-test-docker to a new module security-authentication-test-docker since it's related to security-authentication module now. --------- Co-authored-by: Manuel Leduc <manuel.leduc@xwiki.com> (cherry picked from commit b410dad)
surli
added a commit
that referenced
this pull request
Mar 27, 2024
#3012) Change the mechanism of the reset password token to not reset it at each verification code check, but only when the password is actually reset, and when its lifetime expired. Also provide a mandatory document initializer for the ResetPasswordRequest xclass. Change a bit more the logic: if the token lifetime configuration is set to 0 (which was the default) then we automatically remove the reset password request xobject at first wrong attempt (bad verification code): it will prevent any bruteforce attack. Then if there's a token lifetime configuration set, we don't remove the xobject when a bad attempt is performed: user might have used the wrong mail for example. But we do remove the xobject when it's expired. And if it's expired, or if the code was wrong, in both cases we immediately return an error. Move ResetPasswordIT and ForgotUserNameIT from administration-test-docker to a new module security-authentication-test-docker since it's related to security-authentication module now. --------- Co-authored-by: Manuel Leduc <manuel.leduc@xwiki.com> (cherry picked from commit b410dad)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Jira URL
https://jira.xwiki.org/browse/XWIKI-21571
Changes
Description
Change the mechanism of the reset password token to not reset it at each verification code check, but only when the password is actually reset, or when its lifetime expired.
This PR also provides some refactoring: a mandatory document initializer has been brought for the ResetPasswordRequest xclass and the integration tests for reset password / ask forgotten username have been put in the security-authentication module since the logic is there. Also default value of the token lifetime is now 60 minutes.
Clarifications
Old behaviour of the reset password token was to revoke it immediately at first access, even if the password wasn't reset, or if a token lifetime configuration was provided (which wasn't by default) to use that duration to then revoke it. So basically the mechanism to revoke it was entirely based on access.
Now the mechanism is mainly based on its lifetime, defined by the configuration property which has been set to 1h by default: if the token is accessed after its lifetime duration, the token is revoked and an error is displayed to the user (which has been improved). If the token is accessed before its lifetime duration the token is kept until the password is reset: so if the user doesn't finish the process they can resume it later. Also if the user uses a wrong token (e.g. if they reuse an old token for some reason) the new token is not immediately revoked, as we consider it will be revoked after its lifetime duration. Now if no lifetime duration is provided (old default value of the property was 0) then we do revoke the token at first wrong access for security to avoid any bruteforce.
Screenshots & Video
Executed Tests
Run of
mvn clean install -Pquality,integration-tests,dockeron xwiki-platform-security-authenticationExpected merging strategy