2

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?

4

[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 '16 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 '16 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. – Robyn Jul 7 '16 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. – Mr. AndreasGeo May 22 '17 at 18:41
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.