Re-thinking the website sign-up

There are a bunch of websites where you have to sign up as a user, a proces which normally requires that you hand over an email address which the site will validate by sending you an email with some sort of secret token (a URL) that you need to actually activate the account. As it happens, I’m implementing such a feature at the moment. Assuming that these sites aren’t actually harvesting the addresses for purposes of on-selling them or spamming them directly, it’s usually because they need a way to do things like:

  • prevent a single person from creating an unlimited number of accounts
  • prevent all but the most clever bots from creating accounts
  • permanently ban troublesome users

All of these are perfectly valid concerns. Most sites that I am aware of require you to provide an email address when you create your account, at which time you also choose your username and password (and provide whatever other details are deemed necessary). However, there are problems with this approach, and I think there’s a better way to do it.

Firstly, the traditional approach above potentially allows spamming a person simply by creating accounts and supplying their email address. Although the account can never actually be validated and enabled (assuming the person receiving the validation tokens via email rightfully ignores them), one of two things can happen.

  1. A person could receive a whole bunch of validation token emails which they themselves never requested. Even if it’s not possible to control the content of the emails at all, this could be very annoying to the person, who has to put up with his/her inbox being flooded by the unwanted emails.
  2. A smarter system would only allow one token per email address, and allow further accounts with the same address to be initiated only after any existing token has expired. This limits the number of unwanted token emails a person could be made to receive.

Although (2) above might seem like a nice solution to the problem, it creates a problem of its own – it allows an email address to be denied service. If some mischevious person (call them “A”) wants to prevent another person (“B”) from creating an account, they can just initiate the account creation process using B’s email address and then re-initiate it repeatedly as the token from the previous initiation expires. Of course if B actually does want to create an account, they can use a validation token which A caused to be generated, however they will then be stuck with A’s choice of username and potentially other information which A may have fabricated.

In a similar fashion, it’s possible to block a whole bunch of usernames from being available simply by initiating account creation for each of the usernames, and use a bunch of random email addresses which have either been harvested or made-up (though in the latter case, proper bounce processing might mitigate the effect).

So what’s the solution? Simple: validate the email address before allowing username etc to be chosen. The validation URL will display a page allowing the desired username, password and other details to be entered in the usual fashion, however the email address is already known and verified.

I can’t think of any problems that would be created by doing things this way. Can you?

Advertisements

2 thoughts on “Re-thinking the website sign-up

  1. Oh God! The website sign-up to prevent spam process is a huge sham. Even more so than not allowing liquids on a plane. Here’s how it works from everyone’s perspective.

    WEBSITE DESIGNER : I’ll click the “require registration” box. No more spam on my blog!

    WEBSITE USER : Oh God. Not another one. I can’t trust the website to not harvest email addresses, so I’ll have to use my spam account to create an account here. Why do they keep doing this?

    TROLL : Hahaha! This guy hasn’t heard of yahoo or gmail! I’m going to mess his site up, and there’s nothing he can do except ban my accounts as I create them! Hahaha!

    SPAMMER (without bot) : (same as troll, actually)

    SPAMMER (with bot) : nothing. the bot handles it automatically. (Unless there is a working CAPTCHA, of course, but that is entirely different from requiring registration)

  2. While some of this criticism is valid, I’m keen to hear an alternative. Clearly captchas are one, but they don’t solve all problems (how to prevent repeat spammers? Authenticate identity of legmitimate commenters? Also, bots are becoming clever enough to read captchas).

    Would you consider OpenID (or equivalent) a good alternative from the website user’s point of view?

    Note that I never said validation of identity using email address should be the only anti-spam measure implemented.

    I’d argue that the Troll you’ve described has to go to at least as much (or more) work than the site admins do in deleting his accounts, so (s)he’s not really an issue – Annoying, yes, but not an intractable problem – they key thing is that the creation of these fake accounts can happen only at a limited rate (limited both by how long it takes to create a Yahoo/whatever account, and how long your own site delays before sending out its validation ticket). Also, annoying as some people might perceive it, you could always ban @yahoo and @gmail addresses.

    The same goes for the spammer, with or without the bot. A bot still needs to create the accounts (which requires breaking Yahoo’s captcha) and receive the validation ticket. There’s always the possibility to ban IP addresses as well (and yes, I know that even that is not guaranteed to solve the problem).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s