I work on the iOS implementation of a mobile application where the (cross platform) design guide specifies an unmasking-control for password fields. I am primarily an iOS+Mac user, so this concept was foreign for me, but I did implement it.
Recently, there was a comparison of our app alongside others in an external publication, and we did get less than stellar scores for "security". One of the issues apparently was that a potential attacker could copy the password from an (unmasked) password field.
As a resolution for this problem I suggested that we should get rid of the unmasking-feature, also noting that unmasking is a non-standard pattern anyway. Other team were very adamant that they really like this feature, and that all platforms other than Apple's do have a standard password-unmasking UI in password fields.
We cannot have both – a better security-score and unmasking – so what is the best tradeoff to argue for? Our application does shows privacy sensitive data such as invoices and has features that potentially cost money if (mis-)configured.
I did read the following articles:
- Should password fields have an unmask checkbox?
- Nielsen's Stop Password Masking
- Password UX: the Real Problem
My current opinion is that this arguments from ten years ago are flawed: Making passwords visible at the entry-box makes it harder for users to discern what things are supposed to be secret and doesn't really solve the UX issue with passwords. Password managers or passwordless login systems are a better way to tackle this issue. I would argue to use the platform-specific password-entry field and not add functionality on top of it.
For my comment on the entry of Ro Achterberg I found an interesting implementation of this concept on Windows 10:
Password fields have an unmask-button that only shows up if
- The password field was empty before focusing it
- There is at least one (masked) character in the field
The button is spring-loaded: the password is only unmasked while it is actively being pressed; clicking on it does not move the focus out of the password input.
This looks like a very sensible compromise: Users can check if they entered the correct password, but they cannot uncover passwords from other sources. The spring-loaded nature makes it also a bit more inconvenient to screenshot or copy the text out of the field (on mobile).
Based on the discussion I was made aware that many more people than I expected really like the unmask password feature. A remaining question then is: "If the platform's standard controls do not support such unmasking, should I go out of my way and re-create it, or should I wait for the platform to catch up."
spellcheck=false: androidpolice.com/… .