Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passwords #56

Open
govuk-design-system opened this issue Jan 12, 2018 · 16 comments
Open

Passwords #56

govuk-design-system opened this issue Jan 12, 2018 · 16 comments
Labels
pattern Goes in the 'Patterns' section of the Design System

Comments

@govuk-design-system
Copy link
Collaborator

govuk-design-system commented Jan 12, 2018

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

See also Identifying users

@timpaul timpaul added the pattern Goes in the 'Patterns' section of the Design System label May 21, 2018
@amyhupe
Copy link
Contributor

amyhupe commented Oct 15, 2018

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.

  • 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:

image_preview

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
Copy link
Contributor

joelanman commented Oct 16, 2018

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
Copy link

fofr commented Nov 21, 2018

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

screen shot 2018-11-21 at 13 19 31
screen shot 2018-11-21 at 13 19 38

@idavidmcdonald
Copy link

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
Copy link

@idavidmcdonald I am interested too.

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

image

@NickColley
Copy link
Contributor

NickColley commented Jan 23, 2019

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

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
Copy link

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
Copy link
Contributor

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
Copy link
Member

Password reveal component in the MOJ Design System

@terrysimpson99
Copy link

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
Copy link

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)

@hannalaakso hannalaakso added the awaiting triage Needs triaging by team label Aug 4, 2020
@kellylee-gds kellylee-gds removed the awaiting triage Needs triaging by team label Aug 17, 2020
@36degrees
Copy link
Contributor

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
Copy link
Contributor

@36degrees
Copy link
Contributor

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
Copy link

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
Copy link

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:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pattern Goes in the 'Patterns' section of the Design System
Development

No branches or pull requests