Zuko Blog

How to Stop Passwords Causing Users to Abandon Your Form

Optimizing the Password Field on Forms

This article is part of a series that looks at how to optimize common form fields. Other entries in the series can be found here:

Optimizing the Phone Number Field

Optimizing the Submit Button

Optimizing the Address Field

Optimizing the Title Field

How important is the password field?

Zuko data shows that the password question is typically the most problematic field on forms that ask for it and the reason for this is that we've spent decades creating input patterns that confuse users. This article shares what we've learnt about password fields over the years at Zuko and gives you detailed best practice tips for asking users to create a password online.

However, if you don't have the time to make it all the way to the bottom of the article, our basic advice can be distilled into these 4 points:

  1. Implement minimum length requirements (8 characters+) but complexity requirements are generally unnecessary
  2. Don't ask for confirm password
  3. Use live inline validation to prevent errors in the first place
  4. Make sure users can unmask their passwords


When users create an account on your site, they will usually need to create a password. This, as far as online forms go, can be complex. You as the website owner want the password to be:

These three requirements often lead to password fields adopting some or all of the following approaches:

These techniques can lead to these fields being comparatively difficult for a user to complete successfully, and can therefore lead to use frustration.

Want to understand whether your password requirements are causing users to abandon your form? Get started with a Zuko free trial or demo.

Some Zuko data on password friction

We are committed to using data to improve forms so we did some digging into some Zuko usage data since January 2020, specifically looking at how often users have to return to password fields.

From the above we can see that, on average, almost 50% of sessions have to return to a password field after exiting it, and when they do return they do so an average of twice. In other words, 1 in every 2 people that try to set a password on the above sites get it wrong twice and only move on after the third attempt. That’s a significant amount of friction being put in the way of users.

Even in the best performing fields above, over 30% of users have to return to the password field at least once.

Similarly the lowest average number of field returns was over 1.5 times.

Minimum length and complexity requirements

Short and simple passwords are easier to crack. Sites therefore have traditionally taken steps to force users to create passwords that contain a certain degree of length of complexity. 

For example:

In the above, I have four different requirements on my password that I set. If any of them is not met, I have to choose a different password.

Baymard Institute lists two potential downsides to overly strict password requirements:

  1. Users get frustrated with the password creation process itself. While this is frequently observed, we rarely see it causing abandonments, so long as the password requirements are communicated clearly upfront.
  2. When users are forced out of using their “standard” passwords, they later on are very prone to have difficulties remembering it, and, hence, very frequently experience sign in issues on subsequent visits. This is the true cost of imposing more strict password requirements.”

The first point consistent with data taken from Zuko - 50% of users return to the password field at least twice. This is a significant point of friction for users, and has a detrimental effect on UX.

Baymard also highlights the fact that since a f0rm may require a complex password, a user may ‘make up’ a particularly complex one and, without a password manager, simply not be able to log in further down the line since it would be almost instantly forgotten. The password reset function would therefore be used widely, which is not a great user experience.

The Information Commissioner's Office in the UK provides some clear guidance on password requirements:

“There are three general requirements for any password system that you will need to consider:

  1. password length—you should set a suitable minimum password length (this should be no less than 10 characters), but not a maximum length. If you are correctly hashing your passwords, then the output should be the same length for every password, and therefore the only limit to password length should be the way your website is coded. If you absolutely must set a maximum length due to the limitations of your website code, then tell users what it is before they try to enter a password;
  2. special characters—you should allow the use of special characters, but don’t mandate it. If you must disallow special characters (or spaces) make sure this is made clear before the user creates their password; and
  3. password blacklisting—do not allow your users to use a common, weak password. Screen passwords against a ‘password blacklist’ of the most commonly used passwords, leaked passwords from website breaches and common words or phrases that relate to the service. Update this list on a yearly basis. Explain to users that this is what you are doing, and that this is why a password has been rejected.

Other than the three requirements listed above, do not set restrictions on how users should create a password. Current research (see ‘Further reading’ below) indicates that doing so will cause people to reuse passwords across accounts, to create weak passwords with obvious substitutions or to forget their passwords. All this places unnecessary stress on your reset process.”

Microsoft also recommends avoiding complexity requirements, so despite them being a very common feature of online forms, they are hard for humans to remember. If you need further evidence, this XKCD comics summarises the issue well:

In short, password length requirements are fine (and good), but complexity requirements have a detrimental effect on user experience, and are unnecessary. 

Inline validation (with a difference)

Whichever approach you use to enforcing password length and complexity, password fields offer you a chance to implement instant inline validation.

Rather than wait until the form is submitted, you can provide real time feedback to make sure you are letting users know how close they are to meeting your requirements.

This gives instant feedback, and does not punish a user for getting it wrong - instead it guides them to getting it right.

Should you confirm password?

So a website wants you to be able to login after creating an account with a sufficiently long/complex password. So in order to make sure you set and remember the ‘correct’ password, often you’ll be asked to confirm your initial password entry:

The logic goes - since you entered the password twice, you’ll be twice as likely to remember the password upon your return.

There are a number of problems with this approach.

  1. If the passwords are masked, and your password entry does not match, you cannot tell where you made your mistake:

You therefore have no way to correct either field. You simply have to delete both and try again, hopefully getting it right the second time around.

  1. The first point is compounded by complexity requirements, where onerous additions to passwords will may it all the more likely that a user makes mistakes that they are unable to correct.

  1. Any additional fields within a form take time and effort to complete, even if done correctly. You want to be minimising the amount of mental energy required to complete a form, not adding to that total amount. This field will likely affect your conversion rate.

Take the fields mentioned previously that are confirm password fields:

They still are returned to often and create significant friction. We have our own experience of how removing the confirm password field can improve conversion. You should cut it if you can.

Masking/Unmasking passwords

One way to help users reduce the amount of errors, and meet password requirements more easily, is to allow them to view the characters they are entering into a password field. 

For example, they might be able to to click an icon to the right to unmask the field:

Or a more explicit toggle option to show the password:

Dr Jakob Nielsen argues that we should show most passwords as text when we type them. His article, Stop Password Masking, has the following summary:

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures.

Dr Nielsen also points out two side effects of masking passwords, one of which lowers security:

Users make more errors when they can’t see what they’re typing while filling in a form. They therefore feel less confident. This double degradation of the user experience means that people are more likely to give up and never log in to your site at all, leading to lost business. (Or, in the case of intranets, increased support calls.)

The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a true loss of security.

Dr Nielsen concludes that ‘It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.’

Data taken from Zuko supports this:

Sessions that interact with unmasked password fields return to them at a far lower rate.

Zuko data also suggests that a relatively low number of people choose to unmask their passwords. This may be due to the UI being too subtle or ambiguous with users not knowing how to use the functionality.

We support having the ability to unmask any password. We are not in a 1990s internet cafe anymore - users can generally move themselves to a place of security before creating a password.

Unmasking isn't only for Scooby Doo villains....

Alternatives to passwords which maintain security levels

When reducing complexity requirements

Is it possible to reduce the password requirements without sacrificing security? From Baymard Institute again:

  1. While strong passwords can be particularly important for devices and applications where hackers have unlimited attempts, websites can implement security measures against such attacks by imposing password attempt obstacles and limitations. This removes the potential for brute-force attacks and hence the need for highly complex passwords.
  2. At e-commerce sites we can greatly minimize the consequences of an account breach by not allowing account users to pay with a stored credit card if sending the order to a newly added or edited address (i.e. an address added by a hacker) – without first retyping some of their credit card details. Without the ability to send items to new addresses using a stored credit card, the hacker’s breach of the user’s account becomes less of a security concern, as the severity of the breach is greatly reduced.

More radical approaches

Magic links

A magic link is a unique URL sent to the email account you registered with. Each time you came to login, a new, unique link would be sent to your email address. Clicking the link would log you in, instantly. 

Since you use a password to access your email, and if accessing on a device you would also need to unlock it via a fingerprint or passcode, the security is effectively being outsourced to your email account.

You would therefore not require the setting of a password at all in the account creation process.

Monzo uses this method to allow you to log in, and below are a couple of articles discussing potential implementation of this approach.

https://hackernoon.com/magic-links-d680d410f8f7

https://medium.com/@kelvinvanamstel/should-we-embrace-magic-links-and-leave-passwords-alone-c73db7007fc4

Some discussion of the downsides - https://adam.ac/blog/magic-login-links-are-not-ok/

Codes to phones

Similar to the above, but instead of using email as the identifier, you would use a phone number instead.

Concluding Summary

Pulling this all together, here are our four main recommendations when designing and implementing password fields:

  1. Implement minimum length requirements but, if possible, avoid complexity requirements
  2. Do not ask user to enter their passwords twice
  3. Validate user entries in real time to help them avoid errors 
  4. Give users the option to unmask their passwords

For a broader range of tips and advice to improve your form's conversion and UX, take a look at Zuko's Big Guide to Form Analytics and Optimization.

Looking to improve your form conversion?

Submit your form to get a free health check showing you:
  • Likely friction points leading to abandonment
  • Form elements contributing positively
  • Other areas for UX improvement
Zuko's Big Guide to Form Optimization and Analytics Cover Shot

We wrote the book on form optimization!

"The best book on form design ever written - 80 pages of PURE GOLD"
Craig Sullivan, CEO, Optimise or Die
DOWNLOAD THE EBOOK
(No email needed)

More from our blog:

Video Workshop: Fixing your forms
Check your form for these common UX issues that are causing abandonment
How to Break Your Online Form and Why It’s Good for Business
Uncover UX issues by behaving badly on your form
Failed Form Submissions: Optimizing the Submit Button UX
Why failed submissions happen and how to reduce them
Optimizing the phone number field on forms
UX tips to reduce abandonment on mobile and landline form questions

Zuko is the most powerful form analytics platform available on the market. Find out how to improve your form and checkout conversion by taking a product tour.

PRODUCT TOUR
zuko full colour logo
Formisimo Ltd, Colony, 5 Piccadilly Place, Manchester, M1 3BR
VAT Number: GB181252425
Registered in England as company number 08859680
New Business: sales@zuko.io
Support: support@zuko.io