What about having different validity periods for the different use cases?

lost password: 1 hour, the user triggers the action himself and is waiting for instant email

user creation by signup: 1 hour, the user triggers the action himself and is waiting for instant email

reset password: 3 days, the user asks the admin to reset the password, but does not know when the admin will react, 3 days should be enough to cover time zones and weekend aspects

user creation by the administrator: 30 days should be enough to cover vacation aspect

Maybe add 1 hour (or use configuration option for it) if email is sent by cron job.

@atrol I'm not sure why we will add the complexity of having N different threshold. This just causes confusion when users miss the window. I don't see why we don't have a relaxed deadline. Reasons are:

• If the user's email is compromised, the hacker can issue a new link anyway.
• If user uses the link, we will de-activate the link so it can't be re-used.

Hence, I would go with a single threshold of 30 days and call it a day. Simple, works, and not really an issue in my opinion.

So fix will be as follows:

Replace:
define( 'TOKEN_EXPIRY_ACCOUNT_ACTIVATION', 24 60 60 );

With:
define( 'TOKEN_EXPIRY_ACCOUNT_ACTIVATION', 30 24 60 * 60 );

when creating the constant, i didn't have a strong reason to set it to 24 hours over any other time frame.

@atrol
I dont know what would be the benefit of having a strict short time interval (like the proposed 1-3 hours)
Is there a real use case where it may be necessary?

So, other than some imposed compliance, policies, etc i would not go for complicating the logic for different times.
If any, set it as a config option.

when creating the constant, i didn't have a strong reason to set it to 24 hours over any other time frame.

@cproensa
I thought that security was the reason for it. Seems I was wrong.
I wonder, if we increase from 1 day to 30 days, couldn't we increase to 360 days or remove token expiry?

I was thinking on the self-service scenario, where the user requests the activation through the "lost password" form, for defining at 24 hours.

I wonder, if we increase from 1 day to 30 days, couldn't we increase to 360 days or remove token expiry?

if there is no security risk for going from 1 to 30 days, then technically yes, expiration could be any arbitrary date.

As i said, i can think that a requirement for a different value may come from imposed policies, so this could be left as a (global) config option.

Even if the likelihood of it to happen is quite low, there is a risk that the message is intercepted or the link forged, which could give someone undue access to someone else's account.

While I agree that 24 hours is probably too short in some cases, going for 30 days seems a bit too extreme, and I would propose a shorter delay, say 3 days but no more than 1 week.

I also don't see the reason for differentiated deadlines.

I think of the duration as a way for us to cleanup abandoned invitations rather than a security feature. The interception scenario applies equally to a 1 day duration as it applies to 3 day, 1 week, or 1 month.

I'm OK with a 7 day or 30 days, but nothing less than 7 days. I also don't see a reason for multiple durations.

I'm OK with a constant N days or a config option that is defaulted to the threshold we see as reasonable (7 or 30) days.

PR: https://github.com/mantisbt/mantisbt/pull/956