There are few kinds of links which validate something. For example when you create an account on a website, that website sends you an activating-link. You have to check your inbox and click on the email to activate your account.

As you know, that email isn't valid forever, it will be expired after a while. Why? What's the benefit of expiring links? In other word, what's wrong with keeping them valid until the user uses them?


2 Answers 2


[1] Efficiency:

Assuming you issue a new token for each link for every registration attempt, you will end up with a with a number of tokens that you have to keep track for an indefinite amount of times. For practicality terms I would suggest you set a time/date expiration period depending on the nature of your application.

[2] Security:

In the case of password reset function you want fresh tokens to minimise the likelihood of your token to be guessed or stolen by an adversary. Let's say for example we have a web application that issues a 6 digit password reset token that never expires. It will allow an attacker to initiate the password reset process and guess the correct password via bruteforcing all possible combinations. A time/date expiration will significantly minimise the attack window.

Creating a static token that is valid forever is bad practise. For all the reasons stated above depending on the nature of your web application, tokens must be adequately complex, fairly random and valid only for a reasonable amount of time.

  • 2
    Under security, I would also add minimizing the time window when the token could be stolen somehow.
    – Anders
    Jul 6, 2016 at 16:49
  • I think there is a misunderstood. "you will end up with a number of tokens": I meant wasn't creating a new token for each request, I meant was creating a constant token for an user which is valid forever. So if the user requests a new account-activating link, I will send him a link exactly like the previous one.
    – stack
    Jul 6, 2016 at 17:01
  • Hmm. Even if you accept the overhead of storing one constant token per user, then I would point to the attack window as the reason why not to do so. Also, a constant token would make it harder to trace back a reset to the time and source of the reset request, which I would imagine is a nice thing to be able to do.
    – Robbie
    Jul 7, 2016 at 1:26
  • If the token is a static string, it's even worse. What if your email account is hacked or somehow traffic is sniffed or the token is guessed? It's a good practice to add an element of randomisation in security mechanisms.
    – superhedgy
    May 22, 2017 at 18:41

The reason activation links for activating a account, is timelimited, is because the resulting account is stored in database for a limited time.

Lets say someone registers a account, but enters a invalid email. Now you have a inactive garbage account lingering around in the database for no apparent reason.

In the cases where the link itself contain all information to perform the action, for example a encrypted link containing all the information entered in the sign-up form, or a 2-step sign-up-proces where user first writes their E-mail, then verify it, and then complete the sign-up with a pre-filled E-mail, those solutions can use links with unlimited validity.

For password resets, the links are usually time-limited for security reasons, as the token can leak out or be compromised if left valid too long. For greylisting reasons and E-mail delivery time reasons, I personally recommend a validity of 72 hours for a submitted email (where you don't know if it has been successfully delivered or not, for example if your webhost have a "smarthost" you need to talk to), and a validity period of 1-6 hours for a mail where you can confirm delivery (eg where you are in direct control of the mail server who talks directly to the receiver's mail server).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .