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