views:

69

answers:

3

On a standard web signup form, users are required to have a unique email for the site.

if the email is already in use, a new user cannot be created with that email - but this opens op for exploiting this to find out, what emails are members of the site (at least check if a specific email is in use).

Making sure a bot cannot mass-query is fairly straightforward - but is there a way to avoid it entirely?

The best thing I can come up with is letting the user create process fail with an unknown error and shooting an email to the address in the background, explaining password reset procedures.

Am I missing a better option?

Update:

I want to avoid taking the new user out of the registration process for the 99.9% of the time, when the email is actually unique. So halting the registration process to wait for the user to click a link in an email is not a perfect solution, although maybe viable in some use cases.

+1  A: 

You could print on the web-page something along this:

An email is sent to you to verify the email address. Check your mail and click the included (shared-secret) link.

I.e. you probably have to verify the users email anyway, s.t. you can do it at this location of dialog ...

maxschlepzig
I just really want to avoid taking the user out of the registration process for the 99.9% of the time, when the email is actually unique. I will still send a verification email like you describe in the background though...
Kjensen
A: 

Many sites send a mail to the specified email address containing a randomly generated verification code and only accept the user registration once the user has confirmed they were able to read that mail and obtain the verification code. Usually the mail contains an URL that the user can simply click to confirm.

If you do that, all you need to do is make the confirmation email instead tell the user that they've already registered and explain the password reset procedure.

Whatever web development framework probably has a package that handles confirmation mails.

Note that you have to think about the case where a user had an email address and used it to register to your site, then they vanished without changing the address and stopped using the address, and another user now has the address and wants to register. There's no easy answer here.

ADDED: You add that you don't want a confirmation email so that the registration proceeds immediately. This requirement is contradictory with unique email addresses, because you don't know that the email address supplied by the user is legitimate until it's been confirmed, and there's no point in enforcing the uniqueness of a user-chosen string that just happens to be formatted like an email address (if you want a unique user name, it doesn't need to be formatted like an email address).

If you want to keep instant registration, you'll have to treat email addresses as just an untrusted text field until confirmed. That means that every action that requires your site to send a mail must bomb out if the user hasn't confirm his email address. The confirmation process remains pretty much the same, but now, if the address is a duplicate, the user must either be given the option to merge the two accounts (which sound difficult), or told that he must close one of the two accounts or change the email address associated with one of the two accounts.

Gilles
Having unconfirmed emails does not make sense, no - so I will shoot them an email in the background, and they will need to confirm that before they get access to the stuff for registered users. As I said, it is merely a matter of keeping the process as smooth as possible for the large majority of the users, that do not use a duplicate email and do not enter an invalid email.
Kjensen
+3  A: 

Let the registration continue as normal, but in the confirmation email you should say:

"You allready have an accout bla, click here to cancel this registration, or continue with new registration and delete your current account"

That way, the spammers never know the better, and its very user friendly.

thomasfedb