Wsrtjtyk

Adding to the Daisetsu's answer ( as I cannot write comments yet ).

It would not be bad to create a form and ask user to create password. this way, user would need to enter new password and after submitting it, account would be activated. It would solve the background antivirus check.

As for URL, it should be enough as long, as it's random string. There is very small chance that you will have 2 keys of same content at once.

Checking the IP would not be good as some ISPs may rotate IP addresses so you would block someone who wants to register but cannot.

Your email should include an activation code, not a link. You should not send any link used for account management in an email. If you (the legitimate party) email links (especially with long strings of random characters) to users, then you make it a little more difficult to distinguish legitimate emails from phishing attempts.

The activation code should consist of characters which can easily be copied and pasted (no spaces, '+', '-', etc.) and which are easy to manually enter as well. Letters and numbers work. The security of the activation code depends it being unpredictable. You derive the value using the system's secure random number generator, just as you should be doing with session IDs for cookies.

Activation codes should be stored in a database table, each row with a profile ID, the activation code^*, and the expiration time. You don't want to put the profile ID or expiration time in a cookie, URL, or the activation code.^** A malicious user could tamper with the ID to take over another account. You need to verify those things server-side because your security policy can't be blindly trusting client data.

The activation code should be submitted via a POST request. Automatically redirect users to the account activation URL (which can just be https://example.com/security/activate) when they're done with the rest of the registration. Make it easy to access the account activation page again in case they accidentally close it.

You do not want a GET request to perform any action. A link might get visited without user interaction (due to browser prefetching or email security services). Furthermore putting secrets in a URL could leak sensitive data. (Through referral headers or browser addons.)

Don't worry about the IP, it still may change. (Same for user agent.)

I don't know if a cancellation feature is desirable. I don't even use the unsubcribe links in unsolicited emails because it may be a way to determine whether or not there is a human associated with an email address. If the activation code is long enough to resist brute force or if you limit the number of activation code attempts then I don't see the harm in just letting the activation code expire eventually.

On the other hand it could be nice to reduce the number of unwanted account activation emails. You can limit the number of emails you send to an address, to be polite. Say a maximum of 3 per day and a maximum of 5 per month. (I don't know if that's too high or too low.) As a non-user I would just make emails from your website auto-deleted or auto-marked-read.

There are a lot of variables to consider for unwanted activation emails. Most probably have more to do with user experience than security. You could go as far as providing a "cancel my activation and never send emails to this address because I'm never going to register" feature, but that has obvious problems. (You still need to verify the person's email too.)

_{* It doesn't hurt to hash the activation code. It's also not critical to hash, as with passwords, because each code has a one-time use, contains no private information, is randomly generated by the server, and expires.}

_{** You could actually prevent tampering using a cryptographic MAC, but I would strongly discourage attempting that for most developers. Cryptography is hard to get right.}

As with anything where you are using security practices, the exposure and threat assessment are something which you will have to evaluate for your unique environment and use case. The existing answers provide plenty of touch points for that evaluation, as well as pointers for things to avoid - such as GET triggered actions. Instead, I'm going to focus more on the "user" part of the UX. I will touch on many of the comments scattered about on the page as well.

Exactly what you are "verifying" with the email-triggered action is a factor to consider, as well. If all you are doing is confirming that it is a valid email address, then almost any action will be sufficient. Verifying the email, the intention to create the account, and that the user receiving the email is the user who initiated the account creation requires a bit more effort.

One "effort" you should not have to take, however, is the sending of reminder emails. Assuming the user intentionally created the account, used a valid email address, and wishes to use the account for whatever purpose you are offering accounts, they will be looking for the email, and will undertake the activation process as soon as they are able to. The link, code, or whatever, might expire before they use it if they get sidetracked on other matters while waiting for the email. Allowing them to resend the verification email in such cases is fine. A reminder email, however, is much more likely to be a spam trigger than a benefit to the user.

As a user I appreciate having options available to activate/verify my account. The most common option set I've encountered is where the email provides a link which I can either click or cut & paste, and a confirmation code which I can enter into a form field on a page within my account settings area on the website. Seldom is the confirmation code anything but an integer, 5 to 9 digits long.

The verification emails which give me, as a user, the most confidence are those which have a crypto-looking hash in the URL (/verify?l=lgGS2SBjMTU4NjkwNjYxMjI5MDBhZDk2YjEyMzMzYjNhZmQxOb), which takes me to a page unique to me where I then have to enter the password I used to create the account. The use of the hash confirms that the link was received in an email, not guessed or brute-forced, thus verifying that the email is valid. The serving of that unique page, prior to any other actions, allows the server to mark the email it was sent to as "valid" without confirming the account creation. The entering of the password confirms that there is an actor on the other end, as opposed to some anti-virus, malware detection, or pre-fetch operation. The validity of the password confirms, to a reasonable degree of certainty, that the receiver of the email and the creator of the account are the same person.

The proposed time-limit of 30 minutes does seem a bit severe, while a 24-hour period might be too large if your threat assessment suggests that your exposure in 24-hours is unacceptable. I believe that 2 hours should be sufficient to almost any user's environment. Especially so if the ability to resend verification is available. Even using a mobile device with a 14 kb/s connection to a remote POP account should be able to complete the exchange inside 120 minutes.

The use of JS to somehow verify human actions can be problematic. JS can be turned off, and is much more often than many web developers would like to know. Secondly, ad blockers can block JS on a per-site, or per-source, basis even when JS is enabled in the browser. I block many JS sources, including Google's analytics scripts, on a global basis, and whitelist some for sites, such as Stack Exchange, where I'm willing to support them with the use of my data.

Including a link in the email, or on the confirmation page, to "cancel" the account is a waste. In the email it is actually counter productive in that is suggests that clicking on a link about an account you don't want is a good idea. Instead, the email should include verbiage to indicated that doing nothing will cause the account to not be confirmed, and maybe deleted. A link to cancel on the confirmation page is even worse, as it is rewarding bad behavior. I frequently get emails, as part of an old Google snafu, directed to another Gmail account, and I presume the opposite is true for the other account as well. [In the old days Google didn't merge dotted and undotted user names, so my dotted user name and someone else's undotted version are different accounts, yet Google will slip up once in a while and I get their email anyway :( ]

How tightly you couple the "verified" email address with the activation link is a function of your use case and threat assessment. I am mildly annoyed when I have to re-validate my account after changing the associated email address. How accepting I am of the process is proportional to my "value" of the account. For my bank account, PayPal, etc., I'm 100% accepting. On PcPartsPicker, however, I'd be around 15% accepting of such a process.

As to the IP and/or user agent, ignore them. As a case in point, I often will view sites, and choose to create an account, using my mobile device. I will not, however open emails on it. If I create an account, and learn that I need to verify or confirm it somehow, and email is the offered method, I'll wait until I get home to open the email on my desktop, where I can inspect it. The IP and user agent will thus be very different. My password, however, will remain the same, and that ought to be sufficient to verify me as the original account creator.

Just remember that emails are about as secure as the Jumbo-tron in Times Square, and proceed accordingly.

A verification email needs few things, both for being reasonably safe and user-friendly:

1. It must be clear to the user what's going on. Being explained why this email is being received (e.g. "...someone registered the account BLAH on our site, this is to confirm...") rules out most dumb errors and thwarts fishing mails reasonably well. You hopefully know whether or not you've just registered an account at some service (unless you're completely dement). So, receiving an email which explains this comes as no surprise. On the other hand side, such an email knowing you didn't register anywhere should (well, hopefully) be suspicious enough. If it isn't, and the user clicks on any random link sent via e-mail, there's nothing you could do anyway, not knowing what mails people whom you don't know may or may not receive.


2. A random (non-sequential!) token which is reasonably long (long enough to guarantee it is unguessable and doesn't collide) passed back to the server. That token is also stored in the database for comparison. It doesn't matter how long exactly it is and what particular format it has. It doesn't need to be human-readable. Anything upwards of 20 or so characters (assuming base64 encoding) should work, but I'd use 40 characters to be sure because it doesn't really cost you anything. A 240-bit pseudorandom string is pretty much guaranteed to be unique and unguessable. For convenience, I would actually make it a link, and the link can indeed be a GET request. Yes, users aren't supposed to click on links, but they'll do it anyway (you're not going to educate them!). On the other hand, user experience is much better compared to having to copy-paste some obscure string.


3. A HTML form with a "click to confirm" sort of button which re-POSTs the data, this guarantees that speculative loading of URLs doesn't let stuff happen (unintentionally or even maliciously) that the user owning the mail address doesn't know about. The form should display a reasonable amount of information so the user knows what's going on, and as a last chance to trigger "WTF?" in case the user didn't register that account.
   
   If you're worried about robots, the form can include an "I'm not a robot" if you wish so (personally, I deem that superfluous, but your mileage may vary).


4. A reasonable expiry date (or time). What's reasonable? Nobody can give a definitive good-for-all answer. I'd say anything from 4 hours to two days is probably good. Usually, when you register for something, you get your confirmation mail within 5-10 seconds, and you sit in front of the computer waiting for it. Might be longer if you're using typical paranoia-mode corporate mail which spends minutes on scanning every external e-mail. Though, you might get a phone call or have to go somewhere in the middle of it, so having the token valid for a couple of hours or a day certainly is no mistake. Also, mail can be delayed (rare, but it happens).
   
   On the other hand, there's no point in wasting disk space by keeping around confirmation tokens (and blocking account names!) for weeks, months, or years. Not only does this consume resources to no avail, but someone who doesn't confirm within a day or two probably never will, anyway. Or, they could just re-register another time. Which, really, doesn't cost anything.

From your question, I am taking the following assumptions and if any of them are invalid, so is my answer:

1. the user registers on your webpage and sets username/email and password during registration


2. the e-mail verification has the purpose of ensuring that the user has registered with a proper e-mail address.


3. activation of the account is the only thing that the e-mail link does. It does not allow a password reset or other such functions. It basically does "UPDATE user SET activated=true WHERE token=%1"

In this case, from a security perspective, your approach is absolutely fine. 25 characters gives you enough assurance against random collisions and brute-force attempts, the one-time use protects against sniffing and similar attacks and anyways the only thing someone could accomplish is to activate an account.

You might want to include the user ID if you have a lot of users for performance reasons (UPDATE: not really, see comments below) Finding the user by a string token will result in a table scan, while finding him by ID and then just fetching and comparing the string is an index lookup. However, this does expose the user ID, which you may or may not want to do.