4

Regarding web application user management, I understand that password reset links are effectively "password equivalents", and therefore it makes sense to limit them to one use only and also make them expire.

But what about the email verification links after user registration? This isn't a "password equivalent", just a step to confirm the submitted email address does belong to the user.

Should a time limit also apply to email verification links?

mtmacdonald
  • 143
  • 1
  • 5

3 Answers3

4

A time limit for a verification link is a small part of the overall security model for your system. The main risk-benefit is that if the link is compromised then the same verification link cannot be used in the future (if the user never got around to using the one-time verification link). The link could be compromised by a future user email hack, results being evaluated from network scanning and so on. The theory being that it takes some time to compromise the link itself and then act on it.

It's a pretty low probability risk, however, it makes sense to implement a time limit.

Callum Wilson
  • 2,533
  • 10
  • 15
  • 1
    And it is also a low impact risk, as the account was never commissioned not much private stuff could be put in it. The biggest risk is the reputational risk if the account is closely identified with a publicly known person or organisation. – Andrew Russell May 24 '13 at 04:52
2

It all comes down to risk. There is some risk that the reset link might be obtained by some third party, but how long that might take is anyone guess. If the third party has access to the email account somehow, then it doesn't matter either way, but there is the chance that access might be limited until the user steps away from his/her keyboard without remembering to lock their screen. What it really comes down to is that, for how trivial it is to implement, why wouldn't you make the link expire after 15/30/60 minutes?

Personally, when developing a web-app with a login-reset system, I try to avoid using emailed links on their own unless I absolutely have to. I much prefer a system whereby the user can reset their password on the web-application themselves, requiring them to enter 2/3 pieces of information that was setup when the account was created (and then possibly emailing a link/code/whatever). Usually the information cannot be changed by the user, so that if the account is compromised, the third party cannot lock the real user out from resetting their password.

No method is full-proof, it all comes down to trying to mitigate the risks as much as you can without implementing some sort of Aztec-like ritual involving a blood sacrifice to reset passwords.

Adam McKissock
  • 161
  • 1
  • 7
  • The question was about email verification during registration, not password resets. Also, ['secret questions are not secure'](http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication). – mtmacdonald Jan 18 '13 at 09:34
1

Turn the question around. Why NOT expire verification links? If it incurs little overhead, and there's the possibility that it could increase your users' security to even a slight degree, why NOT? It's likely the time your developer will take to implement it is trivial, which is a win compared to the (admittedly small) possibility of compromise.

Do's and don'ts are usually fairly standard in security. If there's a question, think about it, because the answer is probably on the side of slightly more effort. Yes, you have to use a slow specifically designed hash function for password hashing. Yes, you have to use a standard key derivation function. Yes, you should use HTTPS everywhere. (I'm looking at you, Stack Exchange.) No, you may not write your own cipher.

Community
  • 1
Jonathan Garber
  • 518
  • 3
  • 15
  • 3
    There should be a clear rationale for any security feature. 'Why not' is not a rationale. – mtmacdonald Jan 18 '13 at 09:36
  • It is, in fact. The clear rationale is to eliminate the *possibility* of malicious use of the verification link. Whether or not that risk is small, you have now turned the *security* problem into a *business* one. There is no downside to expiring verification links. There may be upsides. Given that, is making the links expire trivial enough for your developer to implement? If not, why not? – Jonathan Garber Jan 18 '13 at 14:20