Add "request new" button to password reset token expired error

[michag86]

If you create a user without password or use the password reset function, the user gets a mail with the reset link.
This link expires after 24h:
"Couldn't reset password because the token is expired"

For a password reset requested by the user, this is no problem, because the user normally uses the link after request.

But if you create a new user on friday and the user accesses the link on monday, this is a problem.

Why not just add a button to the password expired error, where the user can request a new reset link?

[nextcloud-bot]

GitMate.io thinks possibly related issues are #4352 (Password reset button broken), #6887 (Add LDAP expired password attribute check), #3851 (Add a new calendar from client results in error), #4008 (Disable reset password link), and #10560 (Feature Request: add "Created On" category to one time passwords management).

[MorrisJobke]

Why not just add a button to the password expired error, where the user can request a new reset link?

I like that.

@nextcloud/designers Opinion on this one?

cc @nickvergessen @rullzer because we discussed about this in the past.

[skjnldsv]

What's the proper flow for this?
Button needs admin validation for the new link to be sent out?
If not then we should directly disable the expiration since it won't matter anymore :)

I would suggest to create a special mail for the password definition instead of using the same route as password reset :)
We could then extend the delay to whatever we want and create a config for it (7 days seems good to me)

[jancborchardt]

Extending the validity time or removing it altogether (if that’s fine security-wise) sound good. But even with extended time, a "Request new reset link" button is helpful.

Let’s just not create a config for it – that’s an unnecessary detail. ;)

[michag86]

I would prefer a "Request new reset link" button, because the user is always able to request this from the login page. So why not give him this option in a situation where he needs it. Longer expiration time for tokens would just reduce the number of occurations. And a short expiration time (24h) for the token is ok. Somebody that gets the e-mail with the expired token has no access. Longer expiration time would increase the risk of unauthorized access.

[enoch85]

And a short expiration time (24h) for the token is ok. Somebody that gets the e-mail with the expired token has no access. Longer expiration time would increase the risk of unauthorized access.

I totally agree on this!

I think adding a button where we have the "inactivate", "delete" and "imitate" user would be nice. Name it something like "Send new token" or "Prolong access 24 hours" or something like that.

[rullzer]

So we generate a token of length 21 containing digits, upper case and lower case letters. This means there are something like: 4.3 × 10^37 possible tokens. So it is safe to assume that 'guessing' the token is not what we are worried about here. (and if we do increasing the token length is trivial).

Anyway. Having a 'send new token' makes it effectively useless and a token without expiration date (as the only real way to get the token is to get access to the users e-mail).
I'd need to check but I think that right now. You can just fire off another password reset e-mail. So in basics we already have this 'functionality'.

I don't have strong opinion either way currently. But I'll think some more about it.

[MorrisJobke]

I think adding a button where we have the "inactivate", "delete" and "imitate" user would be nice. Name it something like "Send new token" or "Prolong access 24 hours" or something like that.

This is not about the admin view, but the user view.

I would go with both ways: first make the token work for 1 or 2 weeks (which is fine security wise IMO) and helps to reduce most of the problems and also add a button to resent it once it is expired to give the user this quick option. Also then it would make sense from a user point of view that the token is invalid - "Ah right - I got this 3 weeks ago - I'm fine with pressing the button again and check for the next email".

Does this sound like a sane plan?

[TomTurnschuh]

I personally like skjnldsv's suggestion with a different handling of password definition and password reset also in mails:

I would suggest to create a special mail for the password definition instead of using the same route as password reset :)

Preferably together with the button solution.

In any case, would using the same token but with a different expiration time be an alternative to a single strict expiration time?

[MorrisJobke]

Preferably together with the button solution.

Mmmmh ... implementing another way of doing the same thing doesn't seem to be the correct thing in my opinion. 🤔

In any case, would using the same token but with a different expiration time be an alternative to a single strict expiration time?

Unfortunately there is not "token + expiration date" but only the token and on check the expiration date is hardcoded. But yes - that would be the way to go.

Also it should be fine to extend the period from 12 hours to 7 days, without creating a security issue. cc @blizzz @rullzer

[MorrisJobke]

#10942 changes the time span from 12 hours to 7 days which should mitigate already quite some issues. Additionally there should be a "request new email" for tokens that already expired.