Hassle-free registration and login pages can be quite difficult to create. Here are 10 tips any website should follow.
Make signing up completely optional if you can. The list is not in a specific order, with one exception: this. Users resist registering and they see it as a chore especially if it’s their first visit.
Think if registration is a real need; avoiding it altogether will make user participation surge. For example removing registrations increased revenue by $300 million for an e-commerce website, and 30% of constructive Wikipedia edits come from unregistered users.
Request only the information you need. Users are reluctant and suspicious giving out personal information if the reason you need it is not obvious for them. Because of this it’s a good idea to explain why you need the information:
Cutting down the fields will also make the registration process faster and the page less cluttered. For this reason avoid optional fields altogether; place them in the “Account Settings” page instead.
If the submits the form with an invalid value do not clear the password field, except if the problematic field is the password itself.
This one is a personal annoyance of mine. If I forgot to enter my email why do I have to retype my password (twice)? There are no security reasons preventing the password from being sent back to the browser. It’s in no way less secure than when the browser sent the password in the first place. And yet this practice is almost ubiquitous! Coupled with the lack of client side validation it will probably result in the user punching the screen.
Log users in automatically after they register or reset their password. How many times have you seen the message “Thanks for signing up! You can now login with your username and password”?
Why not log the user in automatically? They just entered their login information seconds earlier, and now they have to do it all over again. The same applies for password resets:
Do not limit the maximum password length. This practice screams “We don’t hash our passwords” and “We don’t know what we’re doing”. Once hashed it always takes the same amount of space in the database and the longer it is the more secure, so there is no reason whatsoever to put an upper limit on its length.
Extreme limits (such as 4,000 characters) put in place to prevent having to hash extremely long passwords clearly entered as part of a DDoS attack are fine.
Additionally, tailor the password complexity requirements based on the type of the website. If it’s a forum about cars do not require a mix of uppercase, numbers and symbols; and if you do, make sure the requirements are clearly spelled out and located next to the field.
Take advantage of client side validation. jQuery validate makes client side validation trivial and the form more user friendly.
For fields that must be verified server side (such as whether the entered username is already taken) make an ajax call and report back to the client while the form is being filled.
If you add a password strength meter, make sure you know what you are doing. Length is what makes a password strong, not the character set used. A long password made up of lowercase letters is much more secure than a short password with alphanumeric characters and symbols.
L4$$so!:)is a terrible password; not “very strong” at all! How Secure is my Password reports that with it would take a desktop computer only 20 days to crack it, and this with a brute force attack. Considering it’s a common english word with common substitutions (a => 4) – that any half decent password cracker attempts – it will get cracked in considerably less time.
Be careful with GET requests. Every time a request has a side effect (such as logging the user out of the website) it must be a POST, not a GET.
The HTTP standard states GET requests must be idempotent (a fancy word meaning “this has no side effects so you can do it more than once”). Based on this requirement browsers are not afraid to perform automatic GET requests, for example to fetch an image. If the logout page accepts GETs and you visit a page containing
<img src="http://example.org/logout" />bam! You are logged out.
Do not overly validate email addresses. RFC 2822 is the official standard that dictates the syntax email addresses adhere to. And it’s not as simple as you may think. Did you know
"hello@world!"@example.comis a perfectly valid email address?
You can use a 426 character regex, reject potentially valid email addresses, or not bother validating them beyond checking if a ‘@’ is present. The last choice is typically the best. If your users don’t want to disclose their real email there is little you can do anyway.
If you use .NET however I suggest to construct a MailAddress object with the entered email –
new MailAddress(email)-; if it throws an exception you should refuse the email as there’s no point in accepting email addresses, even if valid, if you can’t actually send email to them.
Do not limit login attempts. Sometimes you can’t quite remember your password and getting locked out of your own account after the third try is not nice. If the system locks the account itself and not the IP address it can also be a serious security risk: malicious users will be able to lock someone else’s account by entering the wrong password on purpose several times.
A better alternative is to require the user to fill a CAPTCHA after a certain number of attempts instead.