User email verification

What methods do you use.

[mack]

On one of my sites I Allow user registration. As part of the registration process I require the user to provide an email address. I then send the user an email with a link they need to click on order to activate their account.

There are a wide range of situations where you may want or need to do this. It may be to reduce automated signups and/or reduce spam.

What I do is register the user in the normal way, but I have two extra field in my database called "Stalled" and "unique id" the stalled field defaults to 1 and only changes to 0 after the process has been finished. This field indicates that the user has not finished the entire sign up processes (not clicked link in email).

Regarding he link its self. What I do is store the Unix time stamp in the database at registration time. This then becomes a unique ID. The url within the email will then take the form of...
example.com/finish.php?uid=12345&vid=182753647836
uid = user id , vid = verification number
The url contains the user id and the unique id (Unix timestamp) by doing this it is almost impossible for 2 users to have the same unique id. The script that handles the final part of the sign up process also checks that the correct user id (uid) has been sent within the url.

I appreciate that this method isn't perfect, does anyone else have a better solution for such a situation.

Mack.

[Brett_Tabke]

I would encrypt/obfuscate the url string. I would also add some more unique fields to the string. The easier the string is to manipulate, the greater the chances that someone will. There are entire teams of exploiters out there working on this very issue.

[LifeinAsia]

Once the user completes the registration form, he/she gets an e-mail with an initial password. The user can then logon and change the password. The DB has a field for LastLogon. If it's null, the user has never logged on, and essentially unverified. Since the user has to logon before being able to post messages, effectively only verified users can post.

[httpwebwitch]

here's how I verify email address on several of my web apps. Sorry this is a sketchy description of only one part of my authentication; a complete flowchart would take a whole whiteboard

my sql db has two useful tables: USERS and CONFIRMS.

1) user registers, and fills out a form containing email address, name, password, shoe size, marital status, etc. Submit.

2) to process the form, I create a hash, according to this formula: MD5(email.microtime.secretword) where secretword is a string that only I know. I store this hash in the CONFIRMS table in one row along with the microtime and email address, password, shoe size, marital status, and any other data the user provided with their registration. unique PK on the hash field.

3) I send an email to the user, containing a link to my server, thusly:
http://example.com/confirmemail.php?email=___&hash=____

4) When user clicks on that, my confirmemail.php script grabs the row from the db using the hash as its key. If row is found, it checks if the ingredients MD5(email.microtime.secretword) all add up to hash. If they do, then I know the user is responding to the email I sent. Take user's info out of CONFIRMS table and insert it into the USERS table.

5) Send another email to the user, saying Hello and Welcome. Redirect the user's browser to the login page.

* * *

What this establishes factually is that the email address is real and that an agent received and reacted to it. It does not verify that the registrant is human, or that the email address isn't something created temporarily just to get through the registration process.

So, this technique is good for verifying an email address. That by itself is good enough to discourage spammy batch registrations most of the time. I say "most" because as registration + authentication systems go, this one is not a barrier. it's a speed bump.

The real strength of this technique is preventing someone from registering an account using someone else's email address or an invalid/incorrect address. Maliciously, or erroneously.

Email marketers refer to this as Confirmed Opt-In (COI). I've also heard it called "double-opt-in" because the user has opted in twice: once on the web registration form, and again when they click on the confirmation link in the email.

If you really need to make sure the registrant is non-automated, combine this with a captcha, random skill-testing math question, some other kind of closed-loop authentication using telephone or smailmail, or maybe some other turingesque task.