Secure system for verifying e-mail addresses

Question

From this question I really like @woliveirajr's answer because it solves:

1. how to protect against releasing e-mail addresses used on a website
2. verifies the owner of the e-mail address

To avoid this kind of leak, you could also begin the registration process by asking for the e-mail. After entering it, you would send an e-mail with a link so that the user could continue with the registration process. If the e-mail was already registered, you would send an e-mail saying that.

That way, only the owner of the e-mail could register.

Drawbacks:

• probably the real, common users will get bored by having so much steps to register.
• in very few cases simple revealing that an e-mail is already registered in a site is a problem, specially because it's easy to register at any site providing any e-mail that you want. You'll just won't receive the e-mail to activate your account, but in general the site will link the account / username to that e-mail.

Where I'm uncertain is how to implement a system where a user can only access the registration page when they click on a link from an e-mail. Would the registration page retrieve data passed to it using GET and verify "a code" to know whether or not the user can register, and this code changes every 30 minutes? For example, the e-mailed registration link could be mysite.com/register.php?secretcode=as18d and register.php checks "the code" as18d but this code would change every 30 minutes. Is this the idea? Would the code be generated by a salted hash based on the system time?

Or, instead of e-mail a link with a few letters could be e-mailed which the user enters into the registration page to authenticate, kind of like how captures work but not really.

Answer 1

The general approach to this is to use an unguessable token, such as a GUID that is embedded in the link so that it gets submitted with the GET. This should be secure since it is highly statistically unlikely that someone will randomly guess a GUID for any user regardless of the time they spend trying to guess, thus expiration isn't even really necessary.

It is worth noting this should be done over an SSL link to avoid the possibility of a man in the middle compromising the verification process.

Answer 2

There's no way on the server side to guarantee that an HTTP request came from an link in an email message. You can't trust anything from the client side; it can all be spoofed and manipulated.

What you need is a hard to guess token. Long and random are good starting points.

Disagree with AJ on expiration for several reasons.

• If your user db gets large, you don't want to track un-used tokens for years and years.
• If someone requests an activation token and doesn't use it after a few days, it's unlikely they will. Might as well remove it.