Software is Crap

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:

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?