views:

116

answers:

2

I'm working on an application where users can register when they recieve an email invitation for the app. Right now what I do is generate invitation-codes that are sent to the users and stored in the database. The user then goes to the url given in the email which contain the invitation code, like this:

http://myapp.com/user/register/56jk4564k6567kj686kjh56

I was wandering if another aproaches are better, like storing only the email of the user and avoiding sending invitation codes.

Also, using the invitation codes, is there any need of encrypt them?

A: 

yes, you can send a hash of email address along with the link:

 $email = 'foo@bar';
 $check = md5('SECRET' . $email);
 $link = "register?email=$enail&check=$check"

on the "register" page, compute the hash again and compare with the one in the link:

 $email = $_GET['email'];
 $check = md5('SECRET' . $email);
 if($check !== $_GET['check'])
    die("wrong link!");

upd: it's just an example, in the real life you should store the salt outside of the main code:

 $salt = get_salt_from_config_file();
 $check = md5($salt . $email);
stereofrog
Until someone works out all you are doing is hashing the email address and then every script-kiddie can sign up as many times as they want. The word 'SECRET' doesn't really do much - what if this is an open source system?
James
This means that source code known = major security leak. That's not a good thing.
Jasper
@James: make it editable for the site admin (e.g. in the config file).
stereofrog
One more question. What will improve sending the hashing? Before sending the code its stored in the database, so what's the big deal sending a hash if the database don't get hacked?
Fungsten
@stereofrog: putting the salt in the config file still is risky in terms of security. It means that config file known = major security leak. This can for example turn a minor security leak into a very major one. Really, this just isn't a replacement for the randomly generated codes.
Jasper
@Fungstein: The idea of this answer is that you _won't_ have to put the code in your database, as long as you know the email address and the salt, you can always construct it. However, the hashing is done here so that anyone not knowing the salt will not be able to do the same thing, while keeping a user from guessing what the salt is
Jasper
@Jasper: if your config file is readable from the outside world, you're probably having greater problems than just broken registration. Keep your valuables in a safe place!
stereofrog
@stereofrog Yeah, doing random codes for each user is really easy to do. Storing them in the database is not hard. This reminds me of a programmer I used to work with who always jumped straight to a really complex solution to any problem ignoring the easy simple ones that just work. What's the benefit?
James
@stereofrog: You are right, I forgot that for a minute. Nevertheless, I still consider a script working only because a certain value is secret a bad design.
Jasper
+1  A: 

Invitation codes are probably best, as it serves to validate the email address, which means there is one less step to take when the user signs up. Normally you would have to send the user a secret code by email to check the email address is real - well, you've just done that!

One consideration is what happens if a user gets an invitation at one address then actually wants to use a different email address to sign up? Maybe they have more than 1 and want to use a different one? (work vs personal for instance) You'll need the code to validate the person is the same one.

As for Encryption, I wouldn't bother - if your database gets hacked and codes stolen it's easy enough to make new ones and send them out again.

James
Thanks James, that's how it's working, but I didn't thought about the situation you mentioned, I will work on that.
Fungsten