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?

[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.

[dboehmer]

Unfortunately this is still an issue with Nextcloud 17.0.1.

I'd appreciate the error page token expired being redesigned:

• Many user don't know what a "token" is. Better describe that "the password reset link expired".
• It offers no further action–this page is a dead end. If it isn't considered a security risk the users would appreciate a button like "send new password reset link via e-mail".
• The large app icon above the error message showing the Nextcloud or custom icon should be clickable to return to the main page. After all this should offer a last resort to return there and fill out the password reset form from scratch. I think this can't be a security risk.