Update the default reset password link timeout to a longer value

Development
, ,
#1

The current behavior noticed on XWiki 14.10.16, 15.6 is that after opening the reset password link once, the second time is not possible, even if the password reset was not actually done with the link.

The problem comes from cases when depending on the settings on the user’s side or their email client, the reset password link might be pre-read and so it would burn the only time they would be able to use the link.

It would be useful to update the default reset password link timeout to a longer value, such as 1h or perhaps 30 minutes, allowing more time to open the reset password link no matter how many times in that set time after receiving the reset password mail, as long as the password reset is not actually done using that link.

This is a major need, IMO, that improves the usability, as people could miss the opportunity to discover XWiki just because they feel blocked, they are blocked of their local or demo or Cloud wikis.

#2

Hi @AChirica

so to clarify a bit more, your request is about the property security.authentication.resetPasswordTokenLifetime which is by default set to 0, meaning that the token for resetting a password is automatically burnt once first accessed. And you want to change that value to 60 (the value is in minutes).

Honestly I don’t really see the need: this property is documented, any admin can easily change that, and it’s the first time on the forum that I’m hearing about this.
That being said, I don’t really see either a strong issue on changing it: I doubt it would cause a huge security risk. But it’s definitely less secure to not immediately burn that token: anyone intercepting the email could access it even after the user to reset their password and gain access to the users’ account. Right now this scenario is only true if the attacker manage to do it before the user.

So I’m almost -1 to change that, but I’d like to hear other opinions on this.

#3

It’s good that there is a property security.authentication.resetPasswordTokenLifetime already that can be used for that, but it’s not currently present in the UI for Admins so that they can easily change the value. So, even if the default value would not be updated on the product side, it would be great to have the option to update the value in the UI for Admins.

1 Like
#4

Note that there are lots of config properties not exposed in the Admin UI. This is especially true for advanced one that don’t need to be changed often (usually just once).

I’m not saying we shouldn’t expose them, but that you might be hit by some others too.

#5

Hello all

This makes sense but we should also have reasonable defaults.

Given the way this burning works in XWiki - it will prevent you from seeing the password reset twice. I think it doesn’t make too much sense from a functional point of view…

From a functional pov, it makes sense to:

  • not be able to use it again if you used it to actually reset a password,
  • not be able to use it for an indefinite amount of time (for example, it could expire after a while).

There can be many many reasons for which the first usage doesn’t work (security preflight, browser not loading the result of the page, all sorts of browser adventures that may require reloading the link), so there can be many reasons for which at least a second access could be needed. In the case of a preflight, the user may not even know that the link was already accessed.

For these reasons, I am +1 to increase the default duration and change our password reset behaviour to be based on a time expiration. Whether it’s 60 minutes or less or more it doesn’t matter that much, but it should be time interval based.

Also, don’t forget that, because of the implementation, the timeout will start counting when the button is clicked in the wiki, not when the email actually arrives in the inbox of the user. Some delays may be involved, including the time XWiki takes to send the mail (as they’re in a pipe). So maybe a too short duration would not be coherent with the other features of XWiki…

1 Like
#6

I’m not sure about that, on the xwiki.properties file, I can read:

Define the lifetime of the token used for resetting passwords in minutes. Note that this value is only used after first access.

#7

@gdelhumeau I’m not sure I understand what you find contradictory in that documentation…

What I meant in my remark above is that the time starts counting when the “reset password” button is clicked in the wiki, not when the email arrives in the inbox of the user, and that under some conditions, mail delivery from the wiki may take some time.
Thus, since the initial need was just to be able to access the link more than once to allow a preflight of a proxy or so, in theory, we could put a very low timeout, we don’t need 30 minutes, as the proxy will not take 30 minutes to check a URL. However, if we put a timeout of 5 minutes for the token and the email takes a long time to be sent from XWiki / arrive in the user’s inbox, by the time the user clicks the link in the email the time may have already expired.

Now, indeed, as the documentation is saying, this expiration will still allow one access with the token, if that access is the first one. However, in order to actually fix the original problem (which was that a single access may be too little), we need to be able to have at least 2 accesses allowed, so a longer timeout.

Hope it’s clearer now, but lemme know if it’s still unclear.

Anca

#8

No, I don’t understand it that way. I understand that once the link is clicked (or pre-flighted), then you have an additional X minutes of time when you can still re-use that link:

Note that this value is only used after first access.

So we do not really mind about the time the email takes to get delivered.

#9

The doc is indeed a bit ambiguous. The way it currently works is that the duration is checked against when the token was saved, which happens just before the mail is sent. So @lucaa is right here: if the mail takes long to arrive, or if the recipient is taking long to click on the link on the mail the time might have been elapsed already.

#10

Note that instead of the original proposal I think we should probably do what I actually wrote in a private channel:

we can do better, probably by indeed only reseting the token once the password is actually reset, and not when accessing the form, and then use the token lifetime to actually discard it after a duration, no matter if it’s been accessed or not.

#11

So I actually started to work on that in this PR: XWIKI-21571: Change default value of the reset password token lifetime by surli · Pull Request #3012 · xwiki/xwiki-platform · GitHub

It slightly changes the behaviour of the reset token. Main change is that now the token is revoked immediately when its lifetime duration is over and an error is immediately displayed to the user, with a nicer error message. Previous (current) behaviour is that if the token lifetime is over it’s immediately revoked but the user can still perform a password reset once.

Also now the date for knowing when to token expired is based on the reset password request date, and not anymore on the user profile save date.