What not to do with your login/register page

This post is strictly my personal opinions, it does not represent my employer’s views in any way.

Login/register page is essential to any site, especially any Commerce site. You should always follow the proven, established practices, but yet many sites still have issues with their login and register page. Make sure that you do not do anything mentioned below:

• Use HTTP for login/register page.

You might say “What?”. It’s 2016 already and certificate is cheap as hell (even free, if you count Letsencrypt). Still, there are Commerce sites use HTTP for login/register. This, sadly, happens to one of my favorite sites, itsajten:

In case of itsajten, there is not much of sensitive information an attacker can get if he sniffs the network and gets my password. I’m in Sweden and almost everything is transparent, even my income. But still, it does mean that I’m subject to social engineering attack. I notified itsajten about this but never heard from them since – which is a pity. They are otherwise very nice and they offer some of the best prices on the item I interested.

(You might be looking at the address bar – Yes this site is not TLS enabled and I feel bad for it. I did try something but I don’t have total control on the server. You still have the option to comment without logging in to protect your identity. I’ll make sure HTTPS enabled on the entire site as soon as I have time and resources, I promise.)

• Asking too much information:

This, unfortunately, comes from an Episerver reference site: Quicksilver. I don’t think forcing customers to provide their addresses when they register is a good idea. Hey, I’ll provide my address when I actually buy something from you, OK? I don’t want to compromise my information just to register.

If you’re in doubt, follow Amazon’s approach. They just ask for an email address and a password. Nothing else. If the customers mean business, they will provide the necessary information.  It’s has been concluded that the more information you require, the easier you drive your potential customers away. Keep it simple and easy.

• Complex password requirement.

This, again, comes from Quicksilver. Only after customer already chose a password, it says that the password is not good enough. Seriously? 

If you want to constraint something, make sure to show it clearly from start. And it’s been proven that a long password is better than a complex password:

• Use customers email address without consent

This one is from a startup in Sweden – sudio. They sell headphones and related items. One time, I want to check one of their headphones, and I’ve come as far as a checkout page. After inputting my email address, I changed my mind, and close the tab.

Can you guess? 5 minutes later, I received an email from them, offer me a promotion code for 10% discount. It’s neat trick to get your customers engage, but it’s a bit too far. Unless the customer press the Register or Checkout button, they did not agree to give their email addresses to you. You might send it to server for some nice validation check, but never, ever use it without their consent. I felt exploited and walked away from the deal. Don’t do that.

• Send to customer a temporary password without asking them to change.

This one is from a well known site – Ars Technica. Everytime I want to comment something on their posts, I find that I forgot the previous random password they sent me, and I have two options: either find it in my mails, or request them to send me another temporary password. I usually go with the option two, do my comment, forget about it. Then repeat after a while. Yes, I am lazy to find the place to change the password in my User control. But I guess many other users are lazy, too. Better yet, make sure to send the forgetful customer a link to reset his/her password, or ensure he or she changes the password the first time logging in.