Passwords

[govuk-design-system]

Use this issue to discuss this pattern in the GOV.UK Design System.

See also Identifying users

[amyhupe]

Dropbox Paper audit

On 15 October 2018 the Design System team reviewed a Dropbox Paper document called Create a password.

The aim was to reduce the number of places containing guidance and code by:

• migrating relevant, useful content into the Design System itself
• recording important research findings in the community backlog
• removing the original Dropbox Paper page

Below is a record of the outcomes of that review.

Review outcomes

Updates to the Design System

The Design System team will carry out the following updates to ensure that relevant, useful content from the Dropbox Paper file is added to the Design System.

• [x] Add content to the research section of the Design System guidance saying research is needed on inline password validation for users creating a password

Research and examples

The following example was shared in the original Dropbox Paper file and some further research is needed on whether using inline validation to help users who are creating a password is helpful:

If you have experience or examples of using inline validation to help users create a password, please share your findings and screenshots in a comment below.

[joelanman]

I think the gif above is from GOV.UK Verify, that I worked on. We iterated on this pattern - starting without any inline validation, just the password requirements.

We found that users find it very hard to meet password requirements, even with the password visible, as above. Making the requirements status update in realtime helped them understand which requirements they had met, and which they had not.

With less complicated requirements, inline validation may not be necessary.

[fofr]

DFE Sign in have an eye icon to indicate a show/hide password toggle. I don't know how well it tests.

I think the code is here: https://github.com/DFE-Digital/dfe.ui.toolkit/blob/15aade4b481e84839bace40f3773f2d1c66238b2/app/views/change-password-current.html

[idavidmcdonald]

Hi,

I found the password guidance really useful. I had one question that I didn't see covered that I wondered if there was opinion/consensus on. A quick skim of the NCSC guidance didn't find me anything.

When a new user registers and sets their new password (or similar for resetting a password), should you include a 'confirm' field for the password to be entered a second time so you can check it matches the first?

Notify don't appear to - https://www.notifications.service.gov.uk/register The Digital Marketplace appear to - https://github.com/alphagov/digitalmarketplace-user-frontend/blob/20ee069938a4b3bf718eeed49de688d7d215079a/app/templates/auth/change-password.html

Note, this question is more out of my own curiosity when doing some learning about passwords and login patterns so doesn't need a speedy response or any real effort put into investigation.

Thanks!

[stevenaproctor]

@idavidmcdonald I am interested too.

When you create a Government Gateway user ID it asks you to confirm your password.

[NickColley]

This was prompted by a discussion with the Barnardo's Design System team.

To continue @fofr 's example of password masking toggling.

It feels like many services are giving the option to users to toggle a masked password field, is anyone else doing this in production?

Questions

1. What considerations would need to be done regarding accessibility?
2. How well does it test?

Resources

• Stop password masking
• Considerations into custom password accessibility
• Showing Passwords on Log-In Screens
• Summaries of an academic study into password masking

Results prove that unmasked passwords were unexpected by participants and when forced upon them a mixed result is gained. Some appreciate the usability benefits, whilst others believe there is an error on the site. This causes them to lose trust in the buying process.

However when participants are offered the choice of masked or unmasked passwords within the interface, participants identified the concept as a feature not an error. Participants identified the usability benefits of clear text passwords and the security benefits of masked passwords. When participants used this option, there was no impact to trust in the e-commerce website.

Conclusions

• Clear text passwords do increase usability, but don’t force the change upon your customers.
• Offer it as an option and let them use it when they feel comfortable.

[RhysDavi-es]

Has anyone looked into error messages for new passwords? We have a situation where the system could identify that a new password is 'too easy to guess' (i.e. the user is including their name, email, date of birth, etc.). Interested to find out how others are solving this - what does the error message say, do you have different error messages to handle different non-compliance issues (i.e. one for wrong format, another for too easy to guess) or just one?

[36degrees]

It might be good to add guidance around how to use the autocomplete attribute when asking users to change their password – specifically using autocomplete="new-password", to help teams meet WCAG 2.1 1.3.5: Identify Input Purpose.

[hannalaakso]

Password reveal component in the MOJ Design System

[terrysimpson99]

From a slack discussion. The guidance says "show the last typed character of their password". People think this text has been written based on a known pattern which doesn't show the last character indefinitely - it becomes hidden after the next character is typed or after [x] seconds whichever is sooner. Nobody reported having ever seen a service doing it and people thought it would be tricky to do. A show/hide password button might be easier to implement. Comments?

[htmlandbacon]

I asked on slack about this, to see if there was any examples. (thanks for the nudge @terrysimpson99)

It was pointed out on mobile that this functionality happens by default, so I was wondering if anyone had implemented this on desktop? (I started and it seemed super hacky and awful).

I guess the assumption is on desktop the show/hide buttons would be more valuable (people who don't type and look at the screen etc)

[36degrees]

For context, these lines appear to have been taken from the original passwords 'pattern' in the Service Manual:

To help users meet your password constraints and prevent mistyped passwords, you can:

• let them see their password if they want to
• show the last typed character of their password
• make them enter their password twice and automatically compare them

http://web.archive.org/web/20171208002107/https://www.gov.uk/service-manual/design/passwords

[joelanman]

https://incl.ca/show-hide-password-accessibility-and-password-hints-tutorial/

[36degrees]

There's an interesting blog post from GOV.UK Accounts about their 'Show password' functionality: https://technology.blog.gov.uk/2021/04/19/simple-things-are-complicated-making-a-show-password-option/

[philwolstenholme]

https://www.otto-js.com/news/article/chrome-and-edge-enhanced-spellcheck-features-expose-pii-even-your-passwords

This blog post highlights the risks of a 'show password' toggle allowing a user to accidentally share their password (or part of it) with an external (remote) spellchecking service built into their browser. Browsers will ignore spellchecking text within inputs with a type attribute of password, but most of the 'show password' toggle implementations switch that type to be text when the user enables the visibility of their password.

Any implementations should probably set the spellcheck attribute to be false in order to prevent text being sent off for spellchecking.

[CharlotteDowns]

We ran an external accessibility audit for some of the components and patterns in GOV.UK Frontend in May 2023. In that audit, we included an example of the Password component. We’re adding results from that audit here so that we can:

• document, discuss and address the findings
• inform future contributors of the findings

One WCAG AAA issue raised

When there's 2+ password fields on a page, the 'show' and 'hide' labels need to be different

Both of the ‘Show’ buttons presented for users have been provided with an ‘aria-label’ to offer users of screen reading assistive technologies additional context that they are to show the password. However, both buttons have been provided the same name of ‘Show password’, meaning that screen reader users are not able to distinguish which button relates to which field. This same occurs when the button is activated, and the label is changed to ‘hide’.

More detail in this issue:

• #2795