Passwords are pretty straight forward. Just ask for it and stick another field for the user to confirm. Don’t forget to require some obscure logic to have lowercase characters, at least 3 uppercase and 5 special characters while also being meaningful, since all the gibberish can be easily cracked by brute force algorithms. Oh and while not clearly stating the rules to begin with, just say that it’s not good when the user hits submit. Easy… right?

An authentication screen is one of the most viewed screen of your app or website, so no big deal if you get it wrong. Well… it actually is. Turns out that 75% of people who have to reset their password during a checkout process abandon it. Yes, really! (see here). So it’s kind of important to make signing in and signing up as painless as possible.

Avoid password entry altogether

The first tip here is not to use it at all. Certainly this sounds weird in a post about password fields but try to avoid it if you can.

A couple of ideas on what to do:

• Use social login where you can in order to avoid the dreadful account creation process and give the user a head start. The same goes for logging in. If the user can log in with two taps instead of entering email and password, it’s a win.
• Use device features for logging in. You will need a fallback for this, since not all devices support it, but where possible use the fingerprint API (Apple does it, Google does it) to let the user log in. One tap, seamless login.

How to avoid setup frustration

If you have to require passwords, show the rules beforehand. Let the user know what the password should look like. Even if it’s just a length requirement, say from 6 to 20 characters. When setting it up, clearly state all the rules that you are validating against. Oh, and did I say to never require the double password entry. Especially not on mobile. I get it that you don’t want the user to mess it up. Give them the option to enter it in clear text.

Support costs

What does getting it wrong cost on a large scale? The short answer is: a lot. For intranet portals, forgotten passwords are the number one support requests to helpdesk (source). It certainly proves that people struggle with it and the rules are obscure.

Let me tell you a story. My wife, Orsi is a doctor and had to access an Oracle portal of a Canadian pharmaceutical company to enter some medical trial data. Besides the website saying “It requires Internet Explorer 7 to run” (hurray emulation mode) she just couldn’t log in. Now in the middle of the day where we were at the moment, it was the middle of the night in Canada. Probably it didn’t matter, since they are usually outsourcing this, but she just couldn’t log in and had to go throguh the hassle of calling support to reset the password. It took her around 40 minutes from the point of trying to log in to actually logging in successfully, not to mention the frustration and the loss of focus during that time.

How to solve it

There is no golden rule for implementing password entry. Be thoughtful about how you design your forms. Don’t just run off and show the password in plain text. When people only see their password as readable text without any clue or indicator to why, it will worry them. Having an indication next to the field that clearly states how to mask and unmask the password addresses some of these anxieties.

Security issues

The browsers have a remember password functionality. If someone gets their hands on your phone, manages to unlock it and gets to the websites you visited, they could theoretically see your password in plain text. It is possible to implement a logic to avoid this. Detect if the password was populated by the browser, mask it and force them to clear it if they want to unmask or enter a new password.

Notes on forgotten passwords

People forget passwords all the time. Let’s see how you can help them to log in:

1. Send an email to the user with a link to a page where they can set a new password. This verifies the account owner by email and lets them set a new password after accessing the link from the email.
2. Let the user enter a new password and send an activation link in email. This is a similar but different approach to the first one and I think it’s better. First you’re in the moment and can set a new password immediately, so that’s already a win. The next step is verifying the owner by sending an email for confirmation. The hard part is over, from that point on it is easy sailing… the password has been changed, they just need to log in. This lowers the cognitive load on the user the moment the email is received. Otherwise they have to go to a page and then enter the new password.
3. Another option is to let the user log in without requiring a password. You can send an email with a link for instant login. One caveat here is that the user will have to probably change the password after a while, I doubt she will be able to remember it. An idea… you could refine the mechanism by subtly asking the user after login if she wants to set a new password, maybe?

If you are 100% sure the person is on mobile you can send a text message instead of an email. This might be better in some cases, but email works great.

State the rules

Don’t tell the user that the password is not good because it doesn’t comply after hitting submit. Show them the rules from the start.

Using icons

Use icons with the input for showing and hiding the password. You can default to an unmasked field so that the user sees what is being entered. Make sure to use icons that are recognizable (like an eye) Don’t use a lock for locking/unlocking, the user might perceive it as safe/unsafe. If you don’t want to use icons, you can simply change it to “SHOW” and “HIDE”. Using icons helps in internationalization, you won’t have to translate the copy.

Checkboxes

This is very similar to the icon solution. Provide a checkbox below the password field for masking/unmasking. The copy of the checkbox should be adjusted to the default state of the field. If you default to plain text, the checkbox should say something like “Hide Password” and be unchecked.

Passcode

In some cases a full blown password is not necessary. Consider using a passcode or PIN entry. Now with PIN numbers you actually don’t want the show/hide functionality. It is simply a combination of digits and could be a four or six digit number. Use a keypad instead of a full keyboard for entry and have the value masked.

As with everything, you have a number of options. Spend some time to develop the solution that is right for your users. The small details make the difference.