How to verify e-mail addresses?

[Magic2K2]

I need to verify the e-mail addresses of my users when they sign up in order to avoid wasting database space. I have come up with 2 ideas that wouldn't require me using any database space until they sign up and I'd like your feedback on them.

1. Set cookies with user's email, username, password, and activation key. Then, when they read their welcome e-mail, they follow a link and the page they go to will then read those cookies and process their signup.

2. Send the welcome letter containing a link that has the parameters:

?username=something&password=encrypted&email=email

What do you guys think of these two ideas?

I also read somewhere about sending a dynamic image to the user's email address, which would then activate their account as soon as a request is sent for that image (i.e. they opened the message). I'm not sure how to implement this, though.

Thanks for helping.

 

[lucifer]

?username=something&unlock=somethingelse

with an 'unlock' code or just email them a random password that they can then change.

the cookie sounds insecure to me plus never put a raw password in a cookie always encrypt it

 

[jm4n]

I personally use a unique ID for this purpose. Send an email with a "special" URL they must click on, which can be as simple as:

http://blah/confirm.php?UID=hkj6h3h25

The unique ID in my case is obtained by running MD5 on the $UNIQUE_ID environment variable, something Apache comes up with (since the ID itself is semi-sequential, MD5'ing it ensures it looks far more random and is thus harder to guess).

This is stored in a database (along with the rest of their order), and when they click the URL, matching the UID pulls up the correct order and verifies the email address.

My example is done in PHP, but I've done this in Perl and C in the past -- should be adaptable to any scripting/programming language. If you can't get a unique_id in that way, you'll need to generate one with random numbers, time of day, or similar.

<EDIT>
About storing passwords in cookies -- you should never store a password in a cookie, encrypted or not. It doesn't really matter whether it's encrypted, because whatever is in the cookie is effectively the desired response in either case.

IOW, I can read your cookie, make a cookie on my machine, and use that to get into your account. The only difference the encryption makes is that I can't manually type in the password. I can still access whatever pages require the password.

What you want to do is store a Session ID of some sort, similar to the Unique ID. When the user logs in with the right username/password, store the UID and IP address.

If no activity is logged for a certain period of time, consider the login invalid and re-request the login (and create a new UID).

The only thing in the cookie is that UID, which is matched up with the remote IP address and the time (to make sure it isn't expired). Effectively, the UID+IP address combination is your authentication key for a period of time. It's only valid on that IP, and it's only valid for a small amount of time.
</EDIT>

 

[Magic2K2]

I think I'll use the unique ID thing you were talking about...sounds easy enough. One thing though, I don't want to waste database space so what if someone doesn't confirm? Then, that information is just sitting in the activation table taking up space. Is there a way to set the record to expire after say 48 hours? Thanks.

 

[jm4n]

What I do is store an order date -- the date the order was placed -- and run a script via crontab to periodically (once per day) check for unconfirmed orders more than 10 days old. Once ten days has gone by, the order is deleted.

You can certainly change this to 48 hours, and scan more often than once per day. Basically you'd just write a script to look for anything older than xx days/hours/whatever which haven't been confirmed. A one-line SQL query could do this. With MySQL you could use the -e flag, and the whole expiration system would be a one-line crontab entry

At any rate, you could do this with a PHP, Perl, or shell script, or whatever you're comfortable with.

BTW, I should hope you don't have *that* many unconfirmed orders where 2 days worth would hurt you for disk space... One order in my system takes less than 1k of space; it'd take a few million unconfirmed orders before it became a disk space problem... Even a very determined abuser would tire long before submitting this many fake orders

 

[Cheap Bastard]

unless that very determined user has 4 dedicated servers and a script that automatically signs up, you should be in the clear